Batchyx a écrit 1261 commentaires

Pourquoi c'est mort de commencer à parler d'IP à un néophyte ? Tu peux très bien lui dire « IPv6, c'est la même chose que le passage des numéros de téléphone de 8 chiffres à 10 chiffres, ça change rien, mais si on le fait pas, on pourrait plus ouvrir de nouvelles lignes aujourd'hui. Là pour Internet, on passe d'une IP de 4 à 16 octets, pour avoir de la marge et être tranquille. »

Sinon, un service qui m'a toujours fait chier en IPv4, c'est le Wake On Lan. Et va me trouver un remplacent qui n'impose pas d'avoir une machine allumée.

Tu voulais pas parler de masque de signaux, plutôt ?

C'est peut-être parce que j'ai reformatté la chose ...
Si tu veux voir plus en détail l'étendue du désastre par toi-même:

$ pdftk cerfa_13750-03.pdf output cerfa_horrible.pdf uncompress
$ pager cerfa_horrible.pdf

Si un processus lit un pipe avec rien derrière, il ne bloque pas, le read renvoie juste 0, comme à la fin d'un fichier. Pour que ça bloque, il faudrai que quelqu'un ai ouvert le tube et n'écrive rien dedans. Ce serait vraiment mal que le processus fasse ça.

Le seul mécanisme de blocage qu'il peut y avoir, c'est lorsque tu ouvre un pipe nommé fraichement crée en lecture : ton open() va bloquer jusqu'à que quelqu'un d'autre l'ouvre en écriture.

Mais bon, de toute façon, avec un pipe, si il y a deux scripts PHP qui écrivent des choses en même temps, tu va te retrouver avec un mix des deux messages.

Ce n'est pas une bonne idée d'utiliser des signaux pour faire des RPC. Les signaux peuvent être delayés, mis dans une queue voire oubliés, et ils posent des problèmes de concurrences assez difficile (quand un gestionnaire de signal s'exécute, ton programme est dans un état indéterminé, tes structures de données (ou celles de la libc) peuvent être dans un état incohérent (interrompu en pleine mise à jour)). Si tu veux quand même faire comme ça, il faut lire la page de manuel de kill(2), puis la page de manuel de setreuid(2).

Pour corriger le vrai problème, je te conseille plutôt de regarder ce que tu peux faire avec fastcgi, les IPC, la mémoire partagée, les sockets (Unix ou INET*), pour ne citer qu'eux.

Si tu regarde le PDF, tu te rend compte que le message qui est affiché fait vraiment parti du contenu du PDF, ce n'est pas un popup ni quoi que ce soit de spécial, c'est l'unique et (presque) seul contenu.

Si tu passe par une moulinette qui "nettoie" le PDF en virant tout ce qui n'est pas du contenu, tu ne gardera que ce message, ça te fera une belle jambe.

Non, c'est pire, c'est une extension propriétaire à la con, du doux nom de en:XFA, XML Forms Architecture (déjà ça sens le gros bloat). Et pas n'importe quel XFA, c'est le Full XFA dont parle wikipedia : absolument tout le formulaire est contenu dans un gros XML bien bourrin, même des éléments décoratifs :

<draw name="L94" x="11.828mm" y="44.763mm" w="0pt" h="16.758pt"><value>
<line slope="/"><edge cap="butt"><color value="34,30,31"/></edge></line>
</value></draw>

Donc si tu veut ajouter le support de ce PDF à ton logiciel, il va falloir ajouter assez de bloat pour qu'il puisse parser cette horreur:

<field name="NumeroIdentificationVehicule" y="224.576mm" x="11.432mm" w="55.153mm" h="3.392mm">
<ui><textEdit hScrollPolicy="off"><margin/></textEdit></ui>
<font typeface="Arial"/><para vAlign="middle"/>
<assist><toolTip>Numéro d'identification</toolTip></assist>
<traversal><traverse ref="GenreNational[0]"/></traversal>
<validate><message><text name="scriptTest">Le champ " Numéro de voie " n'accepte que les chiffres.</text></message></validate>
</field>

Ah, et ça fait pas partie du standard ISO, bien entendu, c'est juste mentionné, qu'il disent.

Ce n'est possible que si le client envoie un If-Modified-Since. Mais comme tout le monde s'en fout ...

Ah ben 64 Mo, je suis même pas sur que ca passe l'installation de la plupart des distributions, en fait. :)

Debian passe, mais il faut créer le swap (partoche ou fichier) et l'utiliser dès que possible pour pouvoir finir l'installation.

Voyons voir ....

Déjà, c'est crée avec un truc de chez adobe :

xmp:CreatorToolAdobe LiveCycle Designer ES 9.0/xmp:CreatorTool

Et, non content de déjà pas marcher avec un lecteur PDF normal, si on utilise une vielle version d'Adobe Reader, on se prend des messages comme ceux la :

"This PDF file requires a newer version of Adobe Reader. Press OK to download the latest version or see your system administrator.";

C'est très rassurant.

Le reste, c'est un genre de SVG proprio (du XML en tout cas), qui casse pas trois pattes à un canard, et qui n'a pas l'air très utile. NIH, tout ça ....

Généralement, quand t'a une carte qui peut servir comme AP, y a de grande chances qu'elle supporte d'autres trucs marrant, comme pouvoir utiliser autant d'interfaces virtuelles que tu peux en réver.

Dans ce cas, tu peux participer à autant de réseau que t'en a envie (en tant que point d'accès ou pas), à partir du moment ou ils sont tous sur le même canal.

Par contre, attend toi à avoir des performances bien pourries, puisque tu va bien interférer. Si tu reçoit mal un AP, ajouter du trafic sur le même canal ne va pas arranger les choses. Quoi que tu fasse, la capacité d'un canal est limitée ;)

Et surtout, en fonction de ce qu'il y a derrière tes AP public, ce que tu veut faire ne sera peut-être pas possible.

Pour s'imposer dans un marché saturé, Free est forcément obligé d'essayer de casser les prix.

Il y a plein de méthodes différentes de s'imposer dans un marché saturé, autrement qu'en cassant les prix. Demande à Apple ;)

"Tor n'est utile que dans les pays sans liberté d'expression, donc utilisé illégalement, mais aux EU on est libre-euh de dire ce qu'on veux, donc Tor est inutile sauf pour les pirates".

Même lorsque la liberté d'expression est garantie, tu peux quand même t'attendre à des sanctions éxtra-judiciaires si tu signe certains écrits. Tu peux au choix te faire blamer, décridibiliser, insulter, te faire licencier, te faire menacer de mort, te faire enlever ou tout simplement te faire assassiner.

En prenant soin d'être anonyme, on évite ce genre de désagréments.

C'est bien sa comparaison, mais la seule chose qu'il à tésté, c'est la lecture d'un fichier audio, sans savoir quel chip son il utilisait.

Sur les SoC prévus pour téléphones portables que j'ai vu, y a des chips sons qui sont un poil plus compliqué que "une entrée et une sortie". C'est plutôt du genre usine à gaz qui en fait le maximum en hard en supportant genre des entrées/sorties directement relié au modem avec l'encodage avec le codec qui va bien, de l'encodage/décodage A2DP pour le bluetooth, de l'annulation d'écho et de bruit (avec un deuxième micro), ainsi que plein de mixage pour par exemple diriger directement le flux A2DP vers le GSM sans passer par le processeur. Et j'imagine qu'il y a encore bien d'autres fonctionnalités (décodage MP3?).

Est ce que ça supporte tout ça, pulseaudio ?

Après, le fait que ça soit fait sur un truc dédié va peut-être consommer plus, mais va peut-être libérer de la puissance pour le processeur pour qu'il puisse faire quelque-chose d'intéressant, ou tout simplement glander en veille.

Il y a des protocoles que tu ne pourra pas respecter à 100% dans ton réseau local, par exemple DNS (c'est pas standard de mentir).

Si la machine héberge un service que tu peux utiliser légitimement (exemple bateau: serveur web public), tu peux tout simplement ... l'utiliser et capturer le trafic sur ta machine en même temps.

Et à mon avis, tu couvre une bonne partie des besoins rien qu'avec ce cas là. Pas tous, évidement...

ce qui devrait m'allouer un pointeur car c'est ce qu'est Case, et pourtant ça m'alloue une structure

malloc() en à rien à faire de ce que tu alloue, la seule chose qui l'intéresse, c'est sa taille. Si il se trouve que la taille de ta structure est inférieure à la taille de ton pointeur (t'est en 64bits ? les pointeurs sont gros en 64bits ;), tu n'aura aucun problème. Si ce n'est pas le cas, mais que tu n'utilise que les membres qui se trouvent être parmi les premiers sizeof(Case) octets¹ de ta structure, ton code va tourner parfaitement quand même. Et même si tu dépasse, ce n'est pas garanti que ton programme plante (mais ne compte pas la dessus, ça peut planter bizarrement ailleurs, voire pire, fonctionner parfaitement mais avec une faille de sécurité), par contre, c'est presque garanti que valgrind va gueuler.

De manière générale, ce n'est pas parce qu'un code marche chez toi qu'il est correct, portable et qu'il va marcher chez tout le monde.

¹ oui je sais c'est pas des octets mais des "tailles de char", tapez pas.

C'est parce qu'ils se foutent de résoudre des instances réelles du problème ?

Oui, et il n'y a pas qu'eux : Personne sur cette planète n'en à rien à foutre de résoudre le problème. Ce qui les importes, c'est de savoir que "ça c'est dans P".

Peu leur importe de savoir que en fait leur algo était aussi O(n¹⁴·⁷) et qu'on pouvait faire des algos O(n³) avec des améliorations chiantes à prouver. Par contre, les théorèmes intermédiaires (ou la démarche pour les obtenir) pourront être réutilisés pour faire quelque chose d'utile.

Dans la pratique, un algo en O(n⁴²) n'a pas vraiment d'intérêt

Y a des algos exponentiels qui sont utilisés pour traiter des problèmes NP avec des instances avec des tailles en millions. Par contre ils ont des tas d'heuristiques qui détectent les instances ou les parties d'instances faciles ...

Ça dépend lesquels. Ceux qui ont l'habitude de bosser sur des problèmes NP, quand ils tombent sur un algo polynomial, ils sont content, peu importe qu'il soit O(n) ou O(n⁴²).

Mais rééquilibrer ton arbre se fait aussi en O(l log n) : il faut bien comparer ton élément, non ?

Ben, non, justement. Il faut juste regarder la forme de l'arbre et faire les rotations qu'il faut.

Augmenter la taille d'une table de hachage, c'est un coût amorti de O(1), pour peu que tu utilises une progression géométrique.

C'est un coût amorti de O(1) que pour ceux qui considère que hasher une chaîne se fait en O(1). Moi je parlait d'un coût en O(l) pour une chaîne de taille l.

Un théoricien qui considère que comparer deux chaînes se fait en O(1), c'est pas un théoricien.

Hasher une chaîne c'est toujours O(l), alors que comparer une chaîne, c'est O(l), au pire. Si tes chaînes commencent pas par les mêmes lettres (ce qui est courant), ta complexité est bien réduite.

Et la dernière fois que j'ai regardé, rééquilibrer un arbre binaire ça coûte moins cher que d'augmenter la taille d'une table de hachage.

Enfin bref, selon le jeu de données, les résultats sont différents. C'est ça, de la bonne théorie. :)

(La pratique, c'est lorsqu'on se tape le cache du CPU, la rotation des disques et l'OS)

Les tableaux associatifs ne sont pas nécessairement des tables de hachage, surtout pour des chaînes. Ça peut être des variantes d'arbre binaire de recherche, de B-tree, de TRIE ...

Le fait d'utiliser des tables de hachage par défaut dans les langages, c'est bien joli, mais quand on veut des perfs, le mieux est de laisser la possibilité à l'utilisateur de choisir ce qu'il veut. Les tables de hachage avec quelques longues chaînes, c'est pas vraiment idéal.

☑ Parce que les autres l'utilisaient.

Et tu veux faire quoi avec tsocks ?

Indice: ça marche pas avec des threads java.