flan a écrit 1805 commentaires

Le look & feel d'un OS ne se résume pas à un joli thème. C'est aussi tirer parti de toutes les ressources de l'OS.
Pour reprendre l'exemple d'OS X que je connais mieux, une appli bien intégrée va utiliser les API pour les animations 2D/3D (ce sont des fichiers .qtz qui sont réutilisables dans les autres applications), pour le carnet d'adresse, le correcteur grammatical et orthographique, pour la synthèse et la reconnaissance vocale, la gestion des secrets (mots de passe, tokens PKCS11, clefs privées, certificats, …), les images et musiques, le mode plein écran, les raccourcis clavier (modifiable dans n'importe quelle appli Cocoa)…

On peut sûrement faire une liste équivalent pour Linux et Windows (enfin, probablement pas aussi complète, par expérience), mais je connais moins le sujet.

Par contre, point de vue intégration, ce n'est quand même pas top (surtout sur OS X :/)

Je pense que c'est du second degré, en effet. Enfin, je l'espère… :S

Tiens, je ne serais donc pas tout seul à penser qu'il serait temps de réinventer le shell ?

Il y a beaucoup de choses bien en ligne de commande, mais je trouve qu'il faudrait vraiment remettre un coup de jeune par dessus.

• je trouve aberrant de devoir faire du awk, sed, grep, … dès qu'on veut récupérer juste un morceau de résultat (alors que ça se fait naturellement en powershell avec sa représentation objet)
• que le programme adapte sa sortie en fonction de ce qu'il sait du périphérique de sortie (console directe avec couleur ou fichier sans couleur), c'est moche. Ça devrait être au périphérique de sortie de rendre correctement la sortie
• pourquoi deux sorties seulement ? au final, on voit fréquemment l'usage de stderr utilisé comme stdout secondaire, quand on a deux types de sorties
• c'est tout de même très malpratique d'avoir stdout et stderr mélangés par défaut sur un terminal…
• je n'évoquerai même pas l'autocomplétion qui doit être connue du terminal (au lieu d'être fournie uniquement par le programme)

Au final, je trouve la tentative de PowerShell plutôt intéressante (au moins pour le peu que j'en sache), mais pas assez utilisable (à cause de ces commandes trop longues) pour être vraiment réussie.

On peut également dire : « perdre 50% de ses parts de marché en 4 mois, c'est tout simplement énorme » : passage de 2+ % en février à 1% en juin (bon, ok, j'arrondis un peu).

J'ai un peu l'impression que Xen est en perte de vitesse par rapport à KVM. Ce n'est qu'une impression, pas forcément basée sur grand-chose, à vrai dire essentiellement sur le support de KVM par le noyau, par Red Hat, un meilleur support par libvirt (au moins jusqu'à peu), ainsi que par de nombreux gestionnaires de VM (en général, c'est KVM + Xen, ou KVM tout seul).

Du coup, si j'étais DSI (ça tombe bien, je ne le suis pas :D), et si je devais faire un choix entre les deux, je parierais plutôt sur KVM — parce que je trouve que c'est bien un pari à faire, rien d'autre.

(et je ne parle pas des autres solutions de virtualisation, je ne m'y connais vraiment pas assez…)

En terme de sécurité, il y a énormément d'avancées, mais elles ne sont pas toujours très visibles.
Sur le fond, avec Windows 7, je ne vois pas tellement de changements au quotidien par rapport à XP, mais il est vrai que j'en ai une utilisation très basique (qui consiste essentiellement à lancer Startcraft II ou Warcraft III, ainsi que ripper quelques DVD.

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.