flan a écrit 1865 commentaires

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.

oui, ton exemple est un exemple de mauvais code Python. Mais comme déjà dit, on peut faire des trucs sales dans tous les langages, y compris en C.

Mais voilà deux autres exemples de code

current_line = file_descriptor.readline()
current_line = int(current_line) # on sait que le fichier contient que des entiers

=> bouh, c'est sale, on change le type de current_line (de str à int).

int i;
for(i = 0; i < 10; i++) { blablabla }
[...]
i = mon_appel_de_fonction();
i += 42;
return i;

=> ouf, c'est bon, i reste un entier. Pourtant, je trouve que c'est bien pire que l'exemple précédent, vu que la sémantique de i a complètement changé entre les deux utilisations.

Alors, oui, l'inférence de type est plus propre, mais par définition c'est plus contraignant et ne permet pas la souplesse offerte par Python (genre la construction dynamique des types, la récupération des arguments dans un dictionnaire, etc.).

Bien sûr que le duck-typing a un certain nombre d'inconvénients (dont l'absence d'info dans l'IDE fait partie), mais également un certain nombre d'avantages également. Malheureusement, on ne peut pas tous les avantages en même temps, donc il faut faire un choix, et heureusement que tout le monde n'a pas fait le même :)

Au moins, l'approche proposée par Python 3 permet de supprimer à la demande certains des inconvénients. Dans 99% des cas, typer statiquement n'est pas gênant, mais parfois c'est vraiment pas pratique de devoir typer fortement (ou alors on type en « object », ce qui revient à ne pas typer), ou alors on peut construire sa classe peu à peu, remplacer dynamiquement certaines méthodes, etc. J'aime bien la possibilité de mixer les méthodes de programmation, ça permet parfois de bien se faciliter la tâche.

J'essaie déjà d'en faire, mais ce n'est pas toujours évident quand c'est une application graphique :(

Je suis d'accord avec toi.

Simplement, en général, quand je code un algo un peu compliqué, je code par petits bouts, en exécutant les fonctions avec du print un peu partout pour voir si j'ai le résultat attendu à chaque étape.
Au final, je n'ai pas l'impression de perdre tant de temps que ça…

J'ai du mal à utiliser des debuggueur, mais c'est vrai que dans 99% des cas, la stacktrace (quand je fais du Python ou du Java) me suffisent largement.

En revanche, quand je fais du C, j'ai dû ressortir gdb de temps en temps. Et toujours en C, je passe régulièrement un coup de valgrind pour vérifier qu'il n'y a rien de perdu.

« Window$ » … je n'avais pas vu cette écriture depuis bien longtemps. J'imagine qu'on a aussi le droit à iTune$, Googl€, et R€d Hat ?

Quant au /etc dans « Window$ », c'est sûrement parce que Windows est compatible POSIX.

Au passage, je ne vois pas ce que ma réponse a de plus évident.

Cela fait pourtant quelques années qu'Eclipse est en place. Changer d'IDE tous les 15 ou 20 ans, ça reste raisonnable, je trouve.

Je ne suis pas d'accord.

Ce n'est pas parce que tu peux écrire directement dans la mémoire d'une autre machine que c'est le même noyau. Il y a le Firewire qui permet ça (mais je ne pense pas que ça soit le protocole utilisé ;)), et d'autres protocoles réseau, genre Myrinet et Infiniband.