🚲 Tanguy Ortolo a écrit 12091 commentaires

Bah, l'attaquant n'aurait qu'à remplacer ce code JavaScript par du rien…

Il ne faut pas compter sur le contenu transmis pour garantir quoi que ce soit, puisque ce contenu n'est garanti que s'il n'y a pas d'attaque.

Acronym overflow.

que le site web envoie un js

Lapin compris.

que le navigateur envoie des informations au serveur pour vérifier le certificat

Aucun intérêt : si le serveur n'est déjà pas le bon mais celui d'un intercepteur, il répondra sans aucun doute ce que ton navigateur attend.

Un article qui analyse les problèmes du modèle SSL : http://lair.fifthhorseman.net/~dkg/tls-centralization/

Je soupçonne des accords entre sociétés, parce qu'implémenter trop de fonctionnalités utiles nuirait aux éditeurs des logiciels qui comblent ces manques.

(un problème que les Libre n'a pas, d'ailleurs)

Et la possibilité de produire du PDF dans leurs logiciels ? Et un gestionnaire de volumes logiques, fonctionnalité indispensable pour tout serveur de fichiers (entre autres) qui se respecte ?

Je soupçonne des accords entre sociétés, parce qu'implémenter trop de fonctionnalités utiles nuirait aux éditeurs des logiciels qui comblent ces manques.

ce que je fais moi-même quand j'y suis obligé

Je précise encore une fois que je le fais moi-même si c'est nécessaire, mais j'ai l'impression que ça ne devrait pas être à moi de le faire, pour diverses raisons :

• cela donne l'impression qu'il y a un problème en amont puisque le contenu du dépôt ne correspond pas à ce qui est distribué ;
• ce travail n'est pas spécifique à une distribution, et pourrait donc être mutualisé, or la partie commune, c'est justement le travail amont.

Compris pour Vala. Je me permets donc de suggérer de faire, en amont, ce que je fais moi-même quand j'y suis obligé, comme ici :

master
↓ tarball
  ↓
*
| *  ← tarball/2.2.1
|/|
* |  ← release/2.2.1
| |
* |
| *  ← tarball/2.2.0
|/
*    ← release/2.2.0

À savoir : avoir une branche dont le contenu corresponde exactement aux tarballs distribués, à l'exception éventuelle de fichiers .gitignore, branche sur laquelle aucun développement n'aurait lieu, mais remise à jour à chaque nouvelle version. Une telle branche peut évidemment être séparée en plusieurs en cas de maintenance de version antérieure, par exemple :

*    ← tarball/2.4.0
|
| *  ← tarball/2.2.1
|/
*    ← tarball/2.2.0

La cohérence des étiquettes est le point important, plus que celle des branches elles-mêmes, à vrai dire.

À vélo.

• Texmaker et Kile ne pourrait pas fonctionner correctement sous gnome.

Non, là tu interprètes. LaTeXila est un IDE LaTeX pôur GNOME, point. Kile tourne sous GNOME, mais n'est pas bien intégré, alors que LaTeXila vise l'intégration.

Rah. Bon, eh bien on se passera de documentation, si je n'ai pas moyen de la compiler.

En fait non. On va empaqueter ITS Tool. :-)

C'est une recommandation qui me semble douteuse, du moins associée à celle de GNOME de ne pas stocker sous Git des fichiers générés. Parce que le résultat, c'est des tarballs qui ne correspondent pas du tout au contenu du VCS, ce qui est très désagréable pour un distributeur.

La solution que j'applique en tant que mainteneur de paquet, c'est d'assumer moi-même le travail d'adaptation en construisant les commits manquants. Mais je considère que ce travail ne devrait pas m'incomber (et me décomber).

Je ne pense pas que ITS Tool soit déjà packagé sur Debian. Mais ITS Tool est plus ou moins le successeur de gnome-doc-utils si j'ai bien compris, donc de plus en plus de modules de GNOME l'utiliseront (bien que ce ne soit pas du tout spécifique à GNOME).

Rah. Bon, eh bien on se passera de documentation, si je n'ai pas moyen de la compiler.

Autre chose, j'ai finalement opté pour une seule tarball qui contient le code source C généré (comme avant donc), mais il n'y a plus de commit dans Git qui correspond exactement au tarball, puisque c'est déconseillé de mettre dans Git des fichiers générés.

Ça, ce n'est pas cool, mais au pire, je les ferai moi-même, les commits en question, comme pour les autres paquets que je gère dont les auteurs ont cru bon de produire des tarballs qui ne correspondent pas au source, une habitude détestable à mon avis. Mais la vraie question, c'est : pourquoi fournir les fichiers C générés dans le tarball ? Cela supprime la dépendance à Vala, mais à quoi cela sert-il vu que Vala n'est pas un outil exotique et que LaTeXila dépend déjà d'autres outils qui sont bien plus pointus ? ITS Tool, par exemple…

Je suis en vacances, mais dès que je rentre et que j'ai un peu de temps, je m'y mets : si tout va bien, LaTeXila 2.2 sera bientôt dans Debian unstable.

c'est ça l'avantage d'ARM

Non, c'est ça l'avantage d'ARM pour l'embarqué. Or ARM n'est pas intéressant que pour l'embarqué, mais aussi pour les ordinateurs portables et les serveurs personnels.

Par ailleurs, il me semble tout à fait possible de permettre une personnalisation forte tout en fournissant un système de description du matériel disponible et de la façon de l'utiliser plus flexible que le simple identifiant de machine actuel. Par exemple, une table indiquant : à telle adresse mémoire, j'ai un port SATA utilisable avec le pilote orion_sata, à telle adresse j'en ai un second, à telle adresse j'ai une carte réseau Ethernet Gigabit…

Précisément, tu retires le principal avantage à utiliser un core ARM !

Je ne vois pas le raport.

Forcer l'utilisation d'un bus particulier, de registres normalisés,

Déjà, les registres normalisés, ils sont déjà là, heureusement.

Il faut plutôt travailler pour que les interfaces (v4l2, alsa, mac80211, Gallium, ...) soient de plus en plus génériques et permettent de bien spécifier les caractéristiques du matériel, afin que les utilitaires de haut niveau (dbus, xorg, ...) les prennent en compte et les utilisent.

Tant qu'il n'y aura pas une plate-forme normalisée, on en restera à « une machine ⇒ un noyau », ce qui est infernal.

Si (et seulement si), on a un noyau linux porté sur la cible, Linux (le noyau) peut booter et debian être installé.

Faux. Pourquoi Debian s'embêteraient-ils à distribuer plusieurs versions spécifiques du noyau, à ton avis ?

La seule limitation est la manière dont les périphériques sont exportés par le Noyau.

Précisément. Et c'est une limitation de taille : il manque une plate-forme commune aux systèmes ARM.

L'allocation dynamique peut-être ? Pour des données de tailles variable par exemple.

Là j'ai pas trop compris, vous n'avez jamais compiler (avec ou sans patch) votre noyau sur une autre plateforme que du x86 ?

Non, ceci dit je l'ai fait pour x86. Mais ce n'est pas la question : la plate-forme PC permet de rendre ceci facultatif, et permet aux distributions de fournir des noyaux génériques qui tournent partout. Sur ARM, non : la compilation spécifique y est obligatoire.

Quant à des versions arm même si beaucoup de distributions ont arrêté vous en trouverez encore pas mal et pour ne pas la citer les plus connu arch, debian, etc...

C'est vrai, mais, comme je le disais, Debian ARM, ça ne tourne pas sur ARM, stricto censu. Ça tourne sur certains modèles bien particuliers, et le système utilisateur peut tourner sur plein de modèles, à condition de disposer d'abord d'un noyau approprié.

Autrement dit et en plus court, « disponible pour ARM » ça veut dire que le système utilisateur peut éventuellement tourner, une fois qu'on a réussi à démarrer un noyau Linux qu'il faut déjà obtenir.

Attention, n'oubliez pas que dans le monde ARM, il n'y a aucune standardisation, aucune plate-forme au sens où on l'entend quand on parle de la plate-forme PC.

Ainsi, chaque nouveau modèle d'ordinateur implique une adaptation spécifique du noyau Linux. Deux cas possibles :

• le fabricant assure grave et code proprement ses adaptations, puis les intègre au noyau amont ;
• le fabricant craint du boudin et fait son adaptation dans son coin.

Dans le premier cas il y a un chance que l'une ou l'autre distribution propose un noyau permettant de faire fonctionner le modèle en question. Ce n'est pas du tout garanti pour autant, parce que, faute de plate-forme commune, même si les adaptations sont disponibles dans Linux, ça reste grosso modo un modèle, un noyau, donc dix modèles, dix noyaux. Il y a une factorisation sur quelques « plate-formes » comme Marvell Kirkwood mais ça ne va pas bien loin et ça reste très inférieur au modèle PC.

Dans le second cas, il faut compter sur le fabricant pour fournir son noyau approprié…

Les différentes distributions apportent de la fragmentation

Ha ! Et quelle solution est proposée ? Créer une nouvelle distribution !

Dommage que ce soit une nouvelle norme C++ et non une norme C/C++, parce que certaines de ces améliorations pourraient tout à fait s'appliquer au C. Typiquement, le foreach.

Je veux dire, ce qui freine vraiment linux, ce n'est pas tant le problème de driver, l'installation de logiciel ou autres. C'est de ne pas pouvoir regarder le dernier .pptx du boulot ou de la cousine avec un chat trop mignon.

Eh bien écoute, ça n'a jamais gêné personne dans mon entourage, tiens.

???