Dring a écrit 1149 commentaires

Et du coup, quid des journaux qui parlent de Gnome, ce bureau géré par des nazis de l'interface ?

Ben moi j'achète des lames "compatibles" chez Auchan et consorts. Donc format propriétaire, peut-être, concurrence faible ou inexistante, pas d'accord.

Avec le troisième, j'ai vraiment su ce que c'était que de devoir chercher des heures pour trouver 30 minutes de temps libre !

Effectivement, il a utilisé YouTube pour la compression H264. Pour la compression Theora, il a bien mis une keyframe toutes les 10 secondes, cf. "A keyframe interval of 250 frames was used for the Theora encoding".

Comme les geeks libristes n'ont pas d'amis, cette page vide implémente déjà l'ensemble des fonctionnalités dont tu as besoin.

C'est donc bien la version finale du projet.

Certes, mais ça le fait quand même, non ? Le problème avec "extensible", c'est que ça va dans un seul sens. Alors que la notion d'échelle n'implique pas un seul sens ; on peut dimensionner vers plus petit ou vers plus grand.

Curieusement, quand je regarde le wiktionnaire anglais, je vois que "scalable" appliqué au domaine informatique - et uniquement à celui-ci - signifierait forcément "vers plus grand".

Certes, mais ça le fait quand même, non ? Le problème avec "extensible", c'est que ça va dans un seul sens. Alors que la notion d'échelle n'implique pas un seul sens ; on peut dimensionner vers plus petit ou vers plus grand.

Curieusement, quand je regarde le wiktionnaire anglais, je vois que "scalable" appliqué au domaine informatique - et uniquement à celui-ci - signifierait forcément "vers plus grand".

Et "dimensionnable", ça le fait pas ?

Le départ de James Gosling laisse à penser que Java n'est pas un enjeu prioritaire pour Oracle

Je vois pas pourquoi cela "laisse à penser" un truc pareil. Les outils qui accompagnent un Oracle sont tous en Java. Java fait clairement partie des éléments qui intéressaient Oracle.

Il va falloir attendre encore un peu plutôt que de faire des hypothèses aussi hasadeuses.

Tu as raison sur un point : c'est pas avec un unique exemple que je serais convaincu. Mais j'aimerais bien voir un endroit où cette démarche a réellement été déployée partout et n'a pas viré au cauchemar. Je pense sincèrement que ça pourrait faire basculer mes certitudes.

Perso, on m'a "vendu" UML comme une formidable boîte à outil qui permettait de mettre sur papier un système d'information et de le "vendre" à mon tour au client.

Sauf que j'ai jamais vu un non-informaticien capable d'appréhender un schéma UML, même un pov' diagramme "Use Case".

Au final, toutes ces mécaniques ne font que rajouter une couche de travail supposée permettre de mieux se faire comprendre, mais sans y parvenir réellement. En tout cas, c'est ce que j'ai constaté jusqu'ici, et je ne demande que des exemples pour me convaincre du contraire.

Mais quand on travaille dans la vraie vie, on se rend compte rapidement: [...]
Dingue ça. Dire que j'étais persuadé d'être dans la vraie vie, et m'être rendu compte du contraire. Je dois être tombé dans une faille interdimensionnelle sans faire gaffe.

Pourquoi se priver d'automatiser tout ce qui peut l'être, de manière intelligente, et se concentrer sur les choses qui ne peuvent pas l'être ?

C'est très joli, mais les IDE modernes font déjà 99% de ce travail. Quand je veux faire un nouvel objet, je tape juste son nom, la liste de ses propriétés et la complétion fait le reste. Il y a aussi la notion de template et d'assistant pour les morceaux plus complexes.

La plus value à ce niveau là me semble vraiment ridicule.

Si je dois chercher un intérêt, c'est plutôt dans le fait de me focaliser sur un modèle graphique plutôt que sur du code. Mais personnellement, après toutes ces années de code, je me sens plus à l'aise avec du code dont je peux prévoir le comportement qu'avec un générateur automatique que je ne maîtrise pas.

D'autre part, j'ai déjà vu pas mal de projets se fourvoyer à passer des heures, que dis-je des jours et des semaines à créer un zoli modèle UML, à générer un squelette avec, puis à progressivement tout réécrire à la main parce que le "code obtenu n'était pas maintenable" ou "la bidirectionnalité merdait" ou "le générateur n'exploitait pas telle nouvelle fonctionnalité/tel nouveau framework", et j'en passe et des meilleures.

D'où ma question sans réponse pour l'instant (enfin, j'ai pas fini de lire le thread) : est-ce que quelqu'un a déjà vu un gros projet utiliser ce type d'outil ? Est-ce que ça a survécu avec le temps ?

J'ai tendance à penser la même chose, mais peut-être qu'on se trompe. Quelqu'un a déjà vu un gros projet démarré de cette manière et qui a survécu sous cette forme ?

Ouh la la.

La plupart des attaques correspondent à des "types" déjà connu. L'article en énumère pas mal, il y en a d'autres, mais c'est grosso modo un terrain déjà bien déblayé.

Donc je ne vois pas en quoi c'est débile de se baser sur cette liste. Optimiste, à la rigueur, et encore.

Sous prétexte que de nouvelles attaques, voire de nouveaux types d'attaques, sont régulièrement créés, on ne peut pas avoir une approche qui consiste à se protéger de tout ce qui est connu ?

Ca ne veut pas dire qu'en plus il ne faut pas se remettre en cause, mais pour moi c'est un minimum syndical de se protéger des dangers connus.

J'y connais rien en politique mais effectivement ça ressemble à ça.

Il reste quand même la possibilité, au sein d'une même méthode, d'avoir un "else" qui ne peut pas être appelé. Cela vient généralement d'une condition foireuse au niveau du "if", et c'est le signe d'un vrai problème.

Idem avec un "while" dans lequel on ne pourrait pas rentrer, un "do" dont on ne pourrait pas sortir, etc...

OK, merci pour les précisions sur le Zen et le Shuffle.

Pour le firewire, t'es mechant.
J'avoue :-)

Pour firewire, il faut aussi leur reconnaître l'invention du "j'te supprime le port qu'il était tellement bien que t'as tout acheté pour brancher dessus et maintenant t'es niqué si tu veux changer d'ordi faut tout racheter ou te trimballer des adaptateurs à la con".

Sinon, vraies questions : pour l'iPod Shuffle, ça apportait quoi de nouveau ? Et la molette de l'iPod, je croyais qu'ils l'avaient pompé sur les Creative Zen (cf. le procès perdu contre Creative en 2006 qui leur avait coûté 100M de US$).

Dernier point ; "icon", tu fais références aux icônes ? C'était pas déjà dans les protos développés par Xerox ? Idem pour le glisser/déposer et les menus déroulants.

Faudrait voir à pas réécrire l'Histoire non plus.

Sous Win/Gnome/Kde il n'y a pas non plus de bord d'écran pour t'arrêter quand tu ramènes le pointeur du menu option vers la zone ou tu as besoin de travailler.

Si tu es sur une fenêtre non maximisée, tu as un aller/retour forcément plus court quand le menu est dans la fenêtre plutôt qu'au bord de l'écran. Donc ça fait une différence, et donc tout va dépendre de la taille/position de tes fenêtres.

Mais on pinaille vraiment sur n'importe quoi.
Pas d'accord. C'est le genre de petit geste que tu répètes des dizaines/centaines/milliers de fois chaque jour. Dans le cas d'un usage intensif, c'est les petits gestes répétitifs qui font la différence.

La plupart des règles de création d'HIG prennent ça comme point de départ, y compris celles de la marque à la pomme.

Une lecture fort instructive par ailleurs :
http://developer.apple.com/mac/library/DOCUMENTATION/UserExp(...)

Le même genre chez KDE :
http://developer.kde.org/documentation/design/ui/

Peut-être que "les gens qui n'ont jamais utilisé un ordinateur de leur vie" sont devenus extrêmement rare, et tout particulièrement sur linuxfr ?

Les dernières version de MS Office ont été faites dans cette optique (avec le "ruban"), et je trouve que c'est catastrophique. Sans doute parce qu'il est très difficile de trouver des testeurs qui n'ont réellement jamais utilisé un ordinateur de leur vie, et qu'on cherche donc une chimère.

Et après, quand tu dois revenir dans ton application, tu dois te refaire le déplacement dans l'autre sens, mais cette fois il n'y a pas nécessairement de bord d'écran pour t'arrêter...

Pas sûr que tu y gagnes au final. Ca va dépendre la position/taille des fenêtres et de la distance fenêtre / menu.

La multiplicité des copyrights (ou sa détention unique par une entité protectrice du libre comme la FSF) permet d'avoir une forme d'assurance sur la liberté future des projets.

Je suis plutôt d'accord, avec un bémol. Comme on a pu le voir, la multiplicité des détenteurs de droits devient un point de blocage lorsqu'on veut changer de licence (par exemple passer sur la v3 de la GPL), et donc de ce point de vue on perd une certaine liberté.

C'est plutôt cohérent si une ou plusieurs personnes ayant contribué s'opposent effectivement au changement de licence, mais dans certains cas c'est simplement parce que ça rend l'opération irréalisable (retrouver tous les contributeurs, leur demande de valider le changement de licence, etc.). Quand certains contributeurs sont décédés, il faut retrouver les ayant-droits, bref, c'est un cauchemar sans nom.

Le mieux serait donc de passer par une entité protectrice, mais laquelle ? La FSF, c'est bien, mais on n'est pas forcé d'être d'accord avec sa politique. Et puis la confiance, ça ne marche pas toujours. La solution de Monty, c'était aussi de regrouper les copyright sous une société unique, qui était du coup une entité protectrice, et le résultat final est pas génial...

Comme souvent, c'est donc une affaire de compromis : BSD (ou toute autre licence très permissive) vs. GPL détenteurs multiples vs. entité protectrice.

...constatée tous les jours de mon côté.

J'ai beau être un mec, je ne peux pas nier que ma femme est beaucoup plus à l'aise que moi lorsqu'il s'agit d'effectuer plusieurs tâches simultanément.

Qu'est-ce qui te fait dire que c'est une légende urbaine ?

L'article parle d'économiser 22 500 serveurs sur un cheptel de 30 000 machines. Donc, quelque chose d'assez conséquent tout de même. Après, ça ne dit pas si les chiffres correspondent à la réalité.

Juste pour savoir : quand as-tu essayé KDE4 pour la dernière fois ? J'ai eu le même réflexe que toi, j'ai passé 6 sous Gnome, et puis là je viens de retenter ma chance, et sans être révolutionnaire, KDE4.3 est vraiment devenu chouette. Plutôt stable, rapide (avec une Intel intégrée), et très beau.