🚲 Tanguy Ortolo a écrit 12706 commentaires

Franchement, j'adore cette explication. SPDY est-il un remplacement de HTTP, donc ? Non, pas du tout, il remplace HTTP. Sans commentaire.

Non, qu'ils sont impuissants, je crois.

Oups, exact. :-)

man gzip... Compresser des documents en les obfusquant est une connerie, depuis on a inventé des algorithmes de compression

Porte nawak. Les gens en question sont les mêmes qui installent du natif à tire-larigot sur leurs ordiphones.

Je ne sais pas ce que vous en pensez, mais moi il y a un détail qui m'inquiète beaucoup :

Pour ma part, je trouve l’annonce de Dart très décevante. Google a visiblement développé un langage qui correspond à ses besoins (permettre de développer des applications comme GMail ou Google Maps), et en a perdu de vue le plus important : convaincre les autres navigateurs d’accepter Dart.

Vous souvient-il des débuts du Web et des extensions spécifiques incompatibles ? On en souffre encore aujourd'hui, avec des trucs comme Flash. Et après que Mozilla soit passé pour rétablir une situation plus ouverte, voici que Google a :

1. lancé et imposé de façon assez convaincante son navigateur, navigateur qui fait déjà quelques trucs bizarre (genre utiliser un cache DNS perso, voire interroger des serveurs de résolution spécifique...) ;
2. lancé et commencé à utiliser de leur côté un nouveau protocole SPDY ;
3. envisage de remplacer JavaScript pour leur usage personnel.

Ah, oui, exact, c'est fait pour en fait. :-)

Quelques précisions :

• --bare c'est histoire de créer un dépôt « nu » c'est à dire sans répertoire de travail qui ici ne servirait à rien ;
• --shared c'est histoire de configurer ce dépôt pour que les fichiers créés initialement et par la suite quand quelqu'un envoie des données dessus soient en écriture pour le groupe.

Au fait : la façon canonique de procéder avec Git, ce n'est pas ça, mais plutôt chaque développeur qui a son dépôt, et le responsable principal qui va tirer depuis ces dépôts.

Ah, et si ça t'ennuie de fournir un accès shell à tes utilisateurs, tu peux les restreindre en configurant OpenSSH pour les forcer à exécuter un « shell restreint », en l'occurrence un wrapper écrit pour l'occasion, de façon à ce qu'ils ne puissent appeler que la commande git receive-pack.

Crée un utilisateur Unix pour chacun de tes utilisateurs. Crée un groupe Unix pour chaque projet. Crée un dépôt par projet et donne-le au groupe correspondant :

# adduser tintin
# addgroup plop
# adduser tintin plop
# mkdir /srv/git
# git init --bare --shared /srv/git/plop.git
# chgrp -R plop /srv/git/plop 

Et voilà, ton utilisateur tintin peut maintenant accéder en lecture–écriture à ssh://tintin@serveur/srv/git/plop.git.

Une qualité de 100%, ça veut dire que le signal issu de la transformée en cosinus des blocs de l'image n'est pas réduit avant d'être compressé. Donc, avec des logiciels qui respectent réellement la norme, et qui ne mentent pas sur cette qualité de 100% :

1. l'image ne devrait pas être dégradée du tout ;
2. le fichier résultant devrait être identique, à moins qu'il n'y ait des différences dans le compresseur utilisé pour l'étape finale.

En anglais, arms signifie armes

Non, ça veut dire bras.

Je ne sais pas ce que c'est qu'un greenlet, en revanche processus c'est un mot français, équivalent au mot anglais process, et thread, ça se dit fil, sous-entendu fil d'exécution : notez que le sous-entendu est identique en anglais, hors contexte thread ça désigne plutôt un fil de tissu.

Ça me fait un peu penser à http://www.xkcd.org/958/, sauf que ça n'a aucun rapport en fait.

si je ne me trompe, le Klingon arrive en troisième position selon ce critère: cela en fait-il une langue adaptée ? ;-)

Ah, ce serait beau, ça, le klingon comme langue internationale officiellle !

Maintenant je fais comment pour copier ca sur SD, en lui disant bien d'aller chercher le reste de l'OS sur la SD (le switch hardware suffit peut etre ?)

Ça dépend comment ils ont configuré Das U-Boot. Il peut avoir une option pour aller chercher le noyau sur la carte SD. Ou pas. Là encore, il faut demander au fabricant.

Au besoin, je te rappelle que contrairement au PC dont on a l'habitude, ARM n'est pas une plate-forme mais seulement une architecture de processeur et un jeu d'instructions. Ainsi, toujours contrairement au PC, il n'y a aucune généricité, aucun mécanisme de découverte granulaire de matériel, chaque système d'exploitation devant être adapté spécifiquement à chaque modèle à prendre en charge.

En pratique, chaque modèle est spécifique par sa procédure de démarrage, par les composants et périphériques dont il dispose et par la façon de communiquer avec eux. C'est certes toujours le même chargeur de démarrage Das U-Boot qui est utilisé, et qui joue d'ailleurs également le rôle de firmware, mais à chaque fois avec des réglages spécifiques : sur tel modèle il cherche un noyau sur une partition de disque dur formatée en Ext3, sur tel autre il va la chercher en flash...

Il est donc important de noter que la phrase « tel système d'exploitation tourne sur ARM » n'a aucun sens, ou en tout cas pas le sens qu'on y comprendrait quand on est habitué au PC : tout ce que ça signifie, c'est qu'un fois qu'on a réussi à démarrer un noyau adapté sur un modèle donné, le système utilisateur est disponible en code ARM. Mais ça ne signifie pas que ce système d'exploitation est installable et démarrable directement, il faut pour chaque modèle des adaptations spécifiques.

J'espère que ça t'éclairera, mais a priori ça devrait plutôt t'assombrir malheureusement. Il te reste à demander à ton fabricant un noyau adapté et la procédure de démarrage, j'espère qu'ils se montreront coopératifs.

S'il fallait retenir une chose, c'est que la plate-forme PC est une exception et une merveille comparée à la jungle ARM. Quoi qu'aient pu faire IBM par ailleurs, il faut leur rendre grâce pour avoir créé et diffusé une plate-forme ouverte qui a fait gagner des années à l'informatique. Et si l'avenir est ARM, cet avenir est bien sombre.

Excuse-moi, mais il y a un contre-exemple flagrant. Avant Apple, les baladeurs numériques étaient aussi simples à utiliser que des clefs USB : on met les morceaux dedans et ça marche. Apple a apporté deux choses : une roue tactile et une plus grande complexité pour transférer la musique.

Il me semble que le cookie ne sers pas sur localhost donc pas de chiffrement (X11) local

Bien, donc je peux corriger cela : le cookie sert toujours. Essaie un peu de le retirer (xauth list, xauth remove) et regarde le résultat : tu ne peux plus lancer aucun logiciel graphique.

Donc j'imagine que le reste de ce que tu pensais a des chances d'être faux aussi. :-)

Il me semblait que le cookie X11 servait à chiffrer avec un 3DES.

Ça me surprend énormément, parce que cela signifierait que nos sessions X11 sont chiffrées, même en local, ce qui serait idiot.

donc au final ssh -X qui fait le boulot à notre place bien mieux dans 99,99% des cas

Si c'était le cas, faire du déport d'affichage par SSH, cela signifierait surchiffrer par SSH un flux X11 déjà chiffré en 3DES, ce qui serait un beau gaspillage de ressources.

Il n'y a pas de problème à avoir des textes longs en soi, à condition que :

1. ils soient tout de même aussi synthétiques que possible : du texte pour du texte, c'est de la merde à éliminer, hors de la littérature ;
2. ils soient bien structurés, avec 3 ou 4 niveaux de profondeur hiérarchique si nécessaire, et que cette structure soit explicite : la structure implicite à faire deviner au lecteur, c'est de la merde de prof de français–philo.

on peut tout de fois penser

Toutefois.

Jobs au moins a 3 avancée technologiques majeures a son actif, chez RMS ça serait plutôt des régressions...

Ah bon ? Tu peux me rappeler combien de lignes de code iShark a rédigées ces dix dernières années ?

Cool, ils viennent de nous réinventer la liste orange.