flan a écrit 1848 commentaires

Mais la gamme Cell ne s'est pas franchement répandue (elle est même franchement abandonnée), et je ne connais pas tellement la gamme des CPU embarqués, mais je doute qu'elle soit encore très présente :p

Tu veux dire faire plusieurs versions du même dessin en fonction de la taille ? (vu que ça revient à ça)

Autant prendre un bitmap, alors…

Bien sûr que la police est vectorielle, mais ça ne change pas le problème : la taille de la police sur une icône en 1 024x1 024 n'est pas proportionnelle à la taille de la police sur une icône en 128x128. D'ailleurs, on peut même avoir des polices différentes.

Un peu comme j'expliquais précédemment : un dessin très visible mais dont les lignes font 3 ou 4 pixels en 1 024x1 024 passera très mal en 128x128 vu qu'il sera absent, alors qu'il peut être l'information principale de l'icône.

1920x1200 correspond à du 16/10. C'est 1920x1080 qui est du 16/9. </utile>

C'est surtout qu'en l'occurrence, ces icônes ne sont pas destinées à être agrandies (et sûrement pas en 1024x1024). En tout cas, je l'espère, parce qu'avoir un carré en 1024x1024, franchement… :/

(sans compter que je les ne trouve vraiment pas explicites (en plus de ne pas être belles) ; je me demande bien à quoi correspondent le carré, le rond et le losange comme préférences… Le but d'une icône, ce n'est pas simplement de mettre un dessin à la place d'un texte.

Ça fait maintenant quelques années que j'utilise tous les jours des écrans tactiles, et les écrans n'ont pas les traces que tu décris.

En pratique, même pour les formats moyens (64x64), c'est intéressant d'avoir des images différentes de la version 1024x1024. S'il y a du texte sur l'image, par exemple, il faut vite changer la police, ou modifier le texte.

Pour le second : ça m'arrive quand même fréquemment d'avoir pas mal de types de fichiers différents dans un dossier (ne serait-ce que dans mon dossier d'applications), sans compter que tu as toutes les autres images du bureau à gérer (icônes du dock, barre de menu, …). Un image svg bien léchée est très coûteuse à afficher.
Un svg complexe va rapidement prendre 1 Mo sur le disque, et si tu dois en afficher 40 ou 50 en simultané, tu peux être sûr que ta machine va prendre cher.

Mauvaise idée pour au moins deux raisons.

• l'image doit être différente suivant la résolution. Prenons l'exemple d'une icône de dossier avec une note de musique. Si tu veux une image en 1 024x1 024, il faut beaucoup de détails (sinon, ça fait vide), et la note de musique sera assez fine. Elle fera mettons 20px de large, ça suffit largement.

Par contre, quand tu vas réduire cette image, la note de musique va totalement disparaître (car trop fine, elle fait moins de 2% de l'image) alors que c'est le symbole principal de l'image. Dommage, non ?

• les performances. Si toutes tes icônes sont très travaillées (car elles doivent être belles en 1 024x1 024), alors elles sont aussi complexes (dégradés, calculs géométriques, recouvrements, …) à afficher à l'écran. En 1 024x1 024, ce n'est pas grave, vu que tu en auras 2 ou 3 à l'écran. Maintenant, tu affiches le contenu d'un dossier avec plein de fichiers de types différents, et tu te retrouves avec 1 000 images SVG complexes à dessiner. Là, tes perfs en prennent un coup.

Je me demande comment tu fais pour faire de telles taches sur un écran tactile.

Personnellement, j'ai tendance à avoir les mains propres quand j'utilise un objet, peut-être que ça vient de là.

De mémoire (je ne suis pas l'heureux possesseur d'un Macbook Pro Retina, donc je ne peux pas vérifier), les applications qui utilisent le framework Cocoa (donc l'écrasante majorité des applications sur OS X) vont avoir un texte dessiné en prenant en compte ces sous-pixels. Certes, les images ne seront pas à la hauteur, mais c'est toujours ça de pris :)

Maintenant, c'est Cray qui revend (ou a revendu, je ne sais pas) des machines Bull en changeant simplement le logo :)

Rassure-toi, j'ai aussi le problème :)

Bin oui, il y a des problèmes sur OS X… Comme sur tous les OS.

De mon côté, je bosse quotidiennement avec Linux, et j'ai bien plus de problèmes quotidiens (que ce soit des bugs parfois sévères ou simplement de l'inconfort) qu'avec les différents Mac que j'ai eus (ou que j'ai encore). Si je pouvais remplacer ma station de travail par la même chose avec OS X, je le ferais volontiers, d'ailleurs.

Je n'ai pas eu de KP avec OS X depuis plusieurs années, alors que j'ai régulièrement des crash de X. Certes, pas de KP, mais au final ça revient au même pour moi.
Et que ce soit un problème de driver n'est aucunement une excuse, l'expérience de Windows prouve qu'on peut relancer un driver graphique sans tuer la session.
Quand je verrouille ma session avec OS X (ou Windows), elle reste verrouillée. J'ai eu plusieurs mauvaises surprises avec Linux, entre la session qui se déverrouille toute seule au bout de 10 minutes, la session qui reste ouverte alors qu'elle devrait se verrouiller au bout de 5 min, la session qui ne se verrouille plus du tout, etc. Je pourrais continuer assez longtemps comme ça… Alors oui, HFS+ est vraiment moisi comme FS, mais OS X a suffisamment d'avantages pour que certains, même en s'y connaissant bien en système, préfèrent OS X à Linux.

J'ai une petite remarque :
Comme tout projet Django, tous les paramètres sont dans settings.py.

Je trouve ça particulièrement moche, ne serait-ce que l'utilisateur modifie le code d'origine, et si toi tu modifies les paramètres, la mise à jour est délicate.

Une solution est de faire en sorte de mettre des paramètres par défaut dans settings.py, et que ce même module Python aille lire un fichier de configuration pour écraser certains paramètres. Il y a sûrement d'autres solutions, c'est en tout cas celle que j'ai choisie.

Une autre solution plus souple, mais plus laide à mes yeux, c'est de mettre à côté de settings.py un fichier other_settings.py et un fichier default_settings.py.
Dans settings.py, tu peux faire

try:
  from other_settings import *
except:
  from default_settings.py import *

Dans la famille, Salt est assez accessible je trouve. Il n'a sûrement pas toute la puissance de CFEngine, Chef ou Puppet (même s'il ne doit pas en être loin), mais il n'est pas trop compliqué, c'est déjà ça.

Mais dans tous les cas, ce qu'il y a de vraiment compliqué (y compris pour Salt), c'est d'organiser les classes de configuration. C'est vite le bordel, il faut bien le dire :(

Je te rejoins quand même sur le fond : installer des logiciels, ce n'est qu'une étape, il faut ensuite gérer les fichiers de configuration et également garantir que l'état reste stable (donc que le logiciel reste installé, que les fichiers ne sont pas modifiés, etc.)

Il y a l'assurance que personne ne regarde ce que tu fais, et que tu lis la chose que tu veux vraiment lire.

Bon, faut bien reconnaître que pour linuxfr, ce n'est pas non plus super critique.

Ça ne veut rien dire.

Un peu la flemme de lire l'article, à vrai dire, mais il y a pas mal de possibilités :
- des problèmes qui ne sont compliqués à résoudre que dans des rares cas
- la distribution de ses essais n'est pas franchement bien faite et ne sont pas du tout représentatifs de l'ensemble des problèmes
- l'algo n'est pas totalement polynomial :D (de mémoire, il faut qu'il soit polynomial en la taille de l'instance codée en binaire, et non codée en unaire — exemple bateau : trouver les diviseurs d'un nombre est polynomial quand tu codes en unaire mais exponentiel quand tu codes en binaire)

Non, ça met la crypto sur RSA à la poubelle. Il me semble que les méthodes basées sur les courbes elliptiques résisteraient.

pulseaudio va-t-il également s'occuper de la vidéo ? je ne connais pas bien, mais j'ai quand même quelques doutes ;)

Du coup, j'ai essayé Clementine.

Et bien, si je devais l'utiliser, il me manquerait cruellement pas mal de fonctions.

• ça fait uniquement la musique (iTunes s'occupe également des films et des séries TV, sans compter la gestion des iPad/iPhone/…)
• il y a uniquement du transfert de musique avec les iPhone / iPad, et uniquement via USB (la synchro sur iTunes se fait automatiquement par wifi quand je charge mon téléphone)
• je n'ai pas l'impression que ça fasse une synchro complète (i.e. je commence un fichier sur mon téléphone, je continue sur un ordi et je le finis sur un autre : à chaque fois la reprise se fait au bon endroit automatiquement)
• besoin d'avoir un compte pour synchroniser les podcasts (je préfère largement le faire sur mon réseau local, et sans compte)
• impossible de synchroniser partiellement les bibliothèques sur deux machines différentes (i.e. je veux que sur mon ordi portable il y ait la même playlist TOTO que sur mon fixe, mais seulement celle-là parce que je n'ai pas assez de place)
• pas de gestion d'airplay (pratique pour envoyer la musique vers des périphériques dans d'autres pièces)
• pas de télécommande via téléphone

Donc peut-être qu'ils ont plein de fonctions absentes sur iTunes, mais ils ne font pas pour autant tout ce que fait iTunes…

Avec iTunes, dont la bibliothèque est stockée sur un partage AFP avec du RAID5 pour un minimum de sécurité. Au final, ça répond parfaitement à mes besoins, donc je le conserve.

Les iPhone et iPad prennent trop d'importance, apparemment :(

Tu compares l'incomparable. Développer du libre ne coûte pas plus cher que développer du proprio : c'est un fait.

*Ça ne coûte pas plus cher pour le développeur. *
Par contre, pour le client, c'est autre chose : la boîte ne pourra pas revendre le même développement à un autre client, donc ça lui fait un manque à gagner, donc on peut imaginer qu'elle aura tendance à facturer plus cher (pas très fair-play, mais je vois mal les SSII faire des cadeaux à l'administration).

Il se trouve que j'ai dû faire un certain nombre de petits sites web (appli web au boulot, petits trucs perso, …), et même si je n'aime pas spécialement ça, je commence à avoir une certaine expérience (pour un gars dont ce n'est pas le boulot).

Ça fait longtemps que j'ai opté pour du Python + Django, avec des pages relativement statiques (essentiellement parce que je n'aime pas le JS), avec une API REST fournie par Tastypie. Du coup, mes appels JS sont assez limités, et utilisent pas mal JQuery.

Par expérience, il est important de choisir rapidement le type de navigation :
- est-ce que la même URL doit servir pour les petits et grands écrans ?
- navigation possible sans JS ?
- possibilité de partager un lien vers une page quelconque du site ?
Transformer un site existant est en général coûteux en temps quand on n'est pas un pro, donc il vaut mieux partir sur des bases saines à ce niveau là.

Pour la sécurité, c'est un des intérêt d'utiliser un framework comme Django (ou autre) : il y a pas mal de protections de façon native, sans avoir de question à se poser (authentification, mais aussi protection contre les requêtes inter-domaines, etc.)

Nokia n'est pas passé à Windows Mobile, mais à Windows Phone. La différence semble être de taille à l'usage.