Batchyx a écrit 1261 commentaires

Ce que tu dit n'a strictement aucun sens.

lo est une interface réseau. Une interface réseau ne peut pas être intégrée à du code, et ne peut pas filtrer des listes d'éléments à afficher.

Réellement je ne vois pas où est le truc choquant. Ce n'est pas nouveau HTML5 pour créer des applications.

Sauf qu'on parle d'une application de capture réseau là. Le genre d'application qui, dans sa configuration par défaut, va capturer tout tes paquets réseaux en temps réel. Y compris les sessions TCP qui transportent du HTTP et qui contiennent du HTML5, comme … Ton application de capture réseau en HTML5.

Pour ceux qui n'ont jamais fait au moins une fois l'erreur d'utiliser tcpdump en direct dans une session SSH, ça donne ça: tcpdump capture un paquet et l'affiche sur sa sortie standard, qui est rebalancée en SSH. tcpdump voit les paquet de la session SSH dans les deux sens, et les affiche sur sa sortie standard … qui est aussi rebalancée en SSH. En bref ta sortie se fait rapidement floodée par des paquets TCP/SSH et si t'est assez intelligent, tu te rend compte que c'est de ta faute.

Certes, en local, sharkTML5 pourra capturer les paquets réseaux qui ne passent pas par lo, mais la fonctionnalité de capture de paquets passant par lo est utile pour les développeurs réseaux qui testent leur alpha foireuse en local.

En gros, t'est juste en train de réduire les fonctionnalités de ton logiciel rien que pour une fonctionnalité à la mode dont les utilisateurs se foutent.

http://tools.ietf.org/html/rfc4966
http://tools.ietf.org/html/rfc6540

Moi aussi je sais faire des réponses argumentées très constructives.

Il faudrait plutôt faire un atelier de formation à SLAAC ou à DHCPv6.

Parce que c'est bien joli de distribuer des IPv4, mais il y en a plus beaucoup ;)

C'est pas franchement l'atténuation qui pose problème en Wifi … C'est le fait que tu soit pas tout seul à émettre, que le média est partagé et qu'il n'y a pas beaucoup de canaux. Augmenter la portée va augmenter la contention plus qu'autre chose. Tu à plutôt envie d'augmenter le nombre de canaux avec une bande plus large.

Facile, il suffit de mettre le nombre de seconde depuis le nouvel an 1970…

… Ah non, mince, comme le format ne spécifie pas un intervalle de nombre que les implémentations sont obligées de gérer, tu pourrai te retrouver avec des bugs de l'an 2038 si le parseur json décide de te colle ça dans un entier de 32 bit …

Quel truc "aussi basique" ? Quand tu fait du makefile GNU (c'est généralement que tu n'a pas le choix, mais passons), tu peut te retrouver à faire des trucs assez compliqués avec des bugs à l'intérieur.

Effectivement, ça en parle peu. Mais 1 mec qui a passé 10ans de sa vie sur Xorg, qui a écrit ou co-écrit certaines des principales extensions modernes, et qui dit que Xorg "is not network-transparent", je lui accorde un minimum de crédibilité.
Apparemment pas toi, je t'invite à le contacter arguments techniques à l'appui pour lui expliquer SON code…

Moi quand quelqu'un me dit qu'une fonctionnalité que j'utilise n'existe pas ou que personne s'en sert, je vois pas pourquoi j'aurai de l'estime pour lui.

Qu'il considère que la seule définition de transparence réseau est de la transparence pure et qu'il vienne claironner que c'est un mythe, c'est quand même de la putain de mauvaise foi. Personne ici n'a jamais claironné que tout les buffers passent dans une socket Unix ou que tout les appels de rendu OpenGL passent par X. Par contre tout ceux qui utilisent X en réseau sont d'accord pour parler de transparence réseau même si elle n'est pas pure. S'amuser à changer la définition de transparence réseau pour nous faire dire ce que personne n'a jamais dit, c'est de la stratégie de l'homme de paille et c'est prendre les gens pour des cons.

Je t'invite également à lancer Xorg sans ces extensions "optionnelles". Ce sera un grand moment de bonheur.

Le simple fait que X à travers SSH marche fait que désactiver ces deux extensions est non seulement possible mais utilisé par tout ceux qui font de la transparence réseau avec X. Prétendre le contraire est de la mauvaise foi, là encore.

Sinon, utiliser X sans DRI, c'est pas comme si il y avais pas une tétrachiée de personne qui l'ont fait, le font et le feront, et ce sans savoir ce qu'est X ou DRI. Il suffit juste qu'ils n'aient pas d'accélération matérielle qui marche pas hors de la boite, qui n'est pas ou mal installée ou qui n'est pas assez stable pour être utilisée par défaut,

Et là ils l'affirment: on n'ira pas plus loin sans casser X. On attend toujours un dév Xorg qui voudrait démontrer le contraire exposer son projet.

J'affirme pas le contraire. Si X correspond de moins en moins à un besoin desktop d'afficher des effets kikoolol 3D en utilisant une carte graphique bien gérée, surpuissante et directement branchée sur une prise de courant, je suis pas contre le casser.

Mais si le remplacent ne supporte pas les usages moins desktop, il ne faut pas s'étonner que des gens viennent dire que le remplacent est totalement inutile pour eux, parce qu'ils ont parfaitement raison.

Alors quitte à casser X, autant virer tout ce qui est inutile.

Je ne vais pas relever. Avec les développeurs de Gnome, et le système de notation de LinuxFR, on est déjà habitué aux définitions bizarres du mot "inutile".

Et d'ailleurs, tu dis toi-même:

X à été 'network transparent'
Tu admets ou pas qu'il ne l'est pas aujourd'hui, et donc que celui que tu utilises au quotidien ne l'est pas?

J'affirme que le cœur du protocole X était 'network transparent', et vu que tu affirme qu'il n'a pas changé, il l'est toujours.

De toute façon, c'est Libre: tu peux reprendre ou trouver des dévs pour reprendre.

Si je veux de l'affichage qui marche, il faudra bien que je le reprenne, au moins pour les drivers que j'utilise, même si j'aime pas ça. Je suis déjà obligé de le faire pour le noyau Linux, et c'est chiant. Je suis obligé de faire ça pour de plus en plus de logiciels libres (que ça soit personnellement ou professionnellement), et ça en deviens inquiétant.

J'aurai rajouté :

• Le rendu sans freeze du à la contrainte de la perfection au pixel près.

Probablement ce qui me gène le plus avec Windows: l'impression de lenteur atroce que ça donne de geler tout l'affichage jusqu'à que le rendu soit entièrement fini.

C'est toi qui confond depuis le début ce que les développeurs de Xorg dénoncent

C'est plutôt eux qui sont de mauvaise fois totale, ou qui n'ont pas la même définition que le commun des mortels (et je ne vois nul part ou il explicitent la leur)

[Lien vers une conf de 45 min que je suis censé regarder en entier, parce que j'ai rien d'autre à foutre]

Ça n'a pas l'air de parler franchement de transparence réseau, ou si peu.

X est 'network capable' PAS 'network transparent'

Pourtant, X à été 'network transparent', et ton lien indique aussi qu'ils n'ont pas changé le protocole, juste ajouté des extensions optionnelles. Donc le protocole EST transparent. Que les extensions ne le soient pas n'est pas un argument valide, puisqu'elles sont optionnelles et n'ont pas de sens en réseau.

C'est d'aussi mauvaise fois que de rajouter des liens file:// dans une page web et ensuite claironner que le Web n'est plus transparent au réseau.

Et l'expérience n'est pas la même, pas transparente. Capiche ?

Ben non c'est pas la même, puisqu'elle est meilleure à distance dans ce cas…

Si on part sur cet autre définition débile de la transparence réseau, alors elle est impossible quelque soit le protocole et donc n'existe pas.

X en réseau est lent, et donc non transparent. CQFD. Merci.

Et quand X est lent en local, ce n'est plus un serveur d'affichage ?

C'est quand même très débile comme raisonnement alors. Ça veut dire que sur mon vieux portable j'ai de la transparence réseau mais pas d'affichage local avec Xorg ! C'est quand même pas mal pour un "mythe" !

Un peu plus et Firefox n'est plus un navigateur web et ls ne permet pas de lister des fichiers !

L'expérience est-elle la même qu'en locale ?

Tu compare des choux et des carottes.

J'utilise parfois des vieux portables comme terminaux X à une machine fixe plus puissante, et l'expérience est BIEN MEILLEURE qu'en local, même si ce dit portable n'a qu'une interface réseau en 10mbit ou en 802.11g.

Quand je passe par trois tunnels, 2 NAT et un brideur de débit, non, c'est pas la même qu'en local. Mais c'est pas un protocole miraculeux qui va y changer quelque chose, vu que j'ai autant de freezes qu'avec SSH tout seul.

Mais bon, tout cela ne change strictement rien : X en réseau est indistinguable d'une machine lente. C'est largement suffisant pour parler de transparence réseau.

Xorg n'a plus de transparence réseau depuis longtemps, faut arrêter avec ce mythe.

C'est bizarre alors, parce que quand je tape programme & dans un ssh -Y, ça marche de manière transparente pour l'utilisateur, le gestionnaire de fenêtre local et le client (en excluant le toolkit qu'il utilise, certes). Et ça reste utilisable malgré un empilement de 3 tunnels.

Après, que ça n'est jamais été prévu pour, que le code soit moche, soit abusé dans tout les sens et que ça moins efficace que ssh -C xwd | xwud, ce n'est pas pareil que de dire que la fonctionnalité n'existe plus.

Qui a parlé de serveurs ?

Et sinon, oui, les applications graphiques sont parfois utiles sur des serveurs de calculs.

En attendant, X est "good enough". installé par défaut et facilement utilisable.

Alors si il y a un autre protocole de transparence réseau qui se vaut, qui est largement packagé et facilement utilisable, il faut qu'il offre quelque chose de plus qu'X si on veut faire migrer les gens.

Pour ton problème, par exemple, je verrais bien déjà au moins 2 inconnues :

xᵢⱼ : variables binaires: l'étudiant i est dans le projet j.
pⱼ : variable binaire: le projet j est ouvert

On peut déjà commencer à exprimer quelques relations avec ça :

xᵢ₁ + xᵢ₂ + ... + xₙ = 1 (un étudiant est dans un et un seul projet)

xᵢⱼ <= pⱼ (un étudiant est dans un projet seulement si il est ouvert, ça se transforme trivialement en xᵢⱼ - pⱼ <= 0)
x₁ⱼ + x₂ⱼ + ... + xₙⱼ <= 5 (pas plus de 5 étudiant dans un projet)
On peut déjà factoriser ces deux contraintes en une seule :
x₁ⱼ + x₂ⱼ + ... + xₙⱼ <= 5pⱼ (si pⱼ est égal à 0, ça force tout les xᵢⱼ à 0, sinon, ils doivent être inférieur à 5)

Pour forcer le nombre d'étudiant par groupe à être supérieur à 3, il faut une contrainte du même type:
x₁ⱼ + x₂ⱼ + ... + xₙⱼ >= 3pⱼ (si le groupe est ouvert, il doit y avoir 3 étudiants dedans)

(En pratique, pour transformer ces deux relations en égalités, il faudra ajouter des inconnues. On pourrai très bien utiliser ces inconnues et mettre des pénalités pour les groupes de 3 ou 5 ou limiter leur nombre)

Il reste plus qu'a choisir l'objectif. Par exemple, tu peux donner une insatisfaction de 1 si l'étudiant est dans son 2 ième choix, 2 si il est dans son troisième choix … ect. et minimiser la somme des insatisfactions. Tu pourrai être aussi plus fin en cherchant à maximiser la satisfaction et en demandant aux étudiants de noter chaque projet, ça leur permet d'exprimer des opinions plus fines comme "je veux ce projet, tout le reste est indifféremment nul" "j'aime bien ces trois projets, au pire celui là il est bien, mais pas ceux là" "j'en ai rien à foutre".

Pour les groupes, ou bien tu refait les contraintes pour prendre en compte les groupes, ou bien tu fait ça de manière crade, en rajoutant une contrainte "tout ces étudiants font le même projet" et en laissant le solveur simplifier le problème pour toi (ou pas). l'avantage (ou le désavantage) c'est qu'il peut aussi compléter des groupes de 2,3 ou 4 personnes.

Après, pour utiliser ça en python, je sais pas si il existe des bonnes bibliothèques pour ça, mais au pire tu peux lancer lp_solve depuis un programme python et lui donner ton problème en entrée, et parser sa sortie.

(un truc bien avec lp_solve, c'est que sa bibliothèque est une dépendance du solveur d'openoffice/libreoffice, donc il est déjà installé sur pas mal de systèmes)

Moi je commencerai par un programme linéaire en nombre entier.

Le principe, c'est de réduire ton problème à une forme du type:

minimiser A X
tel que B X = C

avec X un vecteur d'entier qui sont les inconnues (et qu'on peut trivialement borner si besoin), C vecteurs de réels constants et B de matrices réeles constantes. Les inconnues peuvent être trivialement bornées, la minimisation peut se transformer facilement en maximisation (suffit de prendre des nombres negatifs dans A), et on peut facilement transformer une égalité en inégalité (si a <= b, alors a = b + inconnue positive)

Sous forme non-matricielle, et en pratique, ça donne :

maximiser a₁x₁ + a₂x₂ + .... + aₙxₙ
avec b₁₁x₁ + b₁₂x₂ + .... + b₁ₙxₙ <= c₁
et b₂₁x₁ + b₂₂x₂ + .... + b₂ₙxₙ = c₂
et b₃₁x₁ + b₃₂x₂ + .... + b₃ₙxₙ >= c₃
et ....
et bₘ₁x₁ + bₘ₂x₂ + .... + bₘₙxₙ <= cₘ

Après, il faut juste choisir ses inconnues et ses variables et éxprimer correctement ses contraintes.
L'avantage de cette méthode c'est qu'elle est éxacte et même si tu ne t'en sert pas pour résoudre, elle permet de prouver que tu est bien à l'optimum. Elle est rapide pour des petits problèmes, par contre, elle peut devenir lente si le nombre de relation/variable éxplose, mais dans ce cas la elle peut proposer des solution intermédiaires.

Le support de la norme C++0x par le ndk (native development kit d'android), quand j'ai commencé mon projet le support n'était pas terrible, j ai donc exclu l'utilisation de la norme et donc des pointers intelligents.
Il restait auto_ptr, mais j'avais lu que auto_ptr et les containers de la STL ne fonctionne pas bien ensemble

Boost à la rescousse !

http://www.boost.org/doc/libs/1_54_0/libs/ptr_container/doc/ptr_container.html

Tout dépend si CastellumLayer deviens propriétaire de l'objet ou non (autrement dit, si il deviens responsable de la destruction du CastellumBox)`.

Si avant l'appel, le CastellumBox appartient à l'appelant et qu'après l'appel il n'appartient plus à l'appelant, alors il faut utiliser ni pointeurs nus ni références, mais des pointeurs intelligents comme std::unique_ptr (ou std::auto_ptr en C++03). Parce que tel que le code est écrit, si push_back balance une exception (genre std::bad_alloc), alors tu peut potentiellement laisser fuiter un castellumBox.

Si CastellumLayer ne deviens jamais propriétaire de l'objet, et que la durée de vie de CastellumBox est correctement gérée (aucun pointeur traîne vers l'objet lors de sa destruction, y compris dans un CastellumLayer::_bricks), alors je dirait qu'il faudrai mieux prendre un pointeur nu, mais ça peut se discuter.

Si CastellumLayer à toujours été propriétaire de l'objet, et que l'appelant à récupéré le CastellumBox depuis CastellumLayer, alors y a peut-être des choses à améliorer dans l'API.

JAMAIS de using namespace xxx dans un header, JAMAIS, JAMAIS! Ça casse l'intérêt principal d'avoir des namespace

Je vois pas le problème avec les using namespace dans les headers, c'est bien pratique parfois dans du métacode. Ça permet d'éviter du code plus poilu.

Faut juste pas le faire dans le namespace global.

Et pis franchement est-ce vraiment plus dur de faire ctrl-e plutôt que ctrl-s?

Plus difficile que de se configurer le raccourci clavier Ctrl+S pour qu'il exporte à la place.

Tout le monde n'a pas le même cas d'usage.

Tu n'a qu'a leur faire programmer des jeux en réseau.

Ce qui est bien avec les jeux en réseaux, c'est que si en moyenne ton jeu merde toutes les 30 minutes, alors si t'en a 6 de lancés à la fois, t'aura des merdes en moyenne toutes les 5 minutes, ça motive un peu plus pour faire les choses proprement ;)

• Vue les taux d’abstention lors des élections, on peut se poser de la question de l'intérêt de la population pour cette activité. Si on me dit que la raison ce sont les élections le problème, regardons du côté de la Suisse et de ses taux d'abstentions records sur nombre de projet de lois provenant de l'initiative du peuple !

Je vois pas ou est le problème avec ça.

Les gens n'ont pas d'avis sur tout. Ils peuvent tout simplement ne pas être concernés ou ne pas se sentir concerné, ils peuvent penser que le projet ne changera rien, ou que les deux choix sont équivalents. Si tu a envie de les forcer à aller voter, alors tu va te retrouver avec des votes de merdes qui ne répondent pas à la question posée.

Mais pour ceux qui sont directement concernés, c'est une grande avancée démocratique puisque tu leur permet de s'exprimer.

Honnêtement, si un projet concernait que le logiciel libre (genre, par exemple, faire reconnaître explicitement par la loi les licenses copyleft), il y aura forcement une grande quantité de personnes qui en auront rien à fouttre, mais c'est pas pour autant que ça ne sera pas une avancée démocratique pour ceux qui sont concernés.

Sauf qu'en pratique, t'a même envie de pouvoir couper le son par onglet. Donc un volume global pour ton navigateur n'est pas suffisant.