soit une organisation au dessus des distributions.
Il y a un truc fait par le projet GNU qui existe depuis longtemps qui s'appelle les autotools et qui fait ça « très bien » depuis des lustres. Faire un .deb depuis un projet autotoolifié c'est très peu de boulot. Après, chacun a sa manière de haïr les autotools, mais bon… et aussi, n-ième standard, toussa…
Rendre obligatoire la conservation d'une ligne de copyright dans un fichier AUTHORS ou dans un menu "about", ca ne me semble pas du tout genant. Par contre en signature de chaque mail, c'est pire que l'ancienne license BSD.
Effectivement, ça me semble complètement délirant ! Le commit est ici :
Je pense que ça n'a rien à voir avec la condition de raison de la clause 7. Bref, on a deux acteurs qui dans un sens comme dans l'autre (puisque Blue Mind avait l'air, avant d'être revenu en arrière, de vouloir proposer des versions commerciales de logiciels libres) à des gens qui veulent abuser du Libre et se tirent là bourre commercialement, et maintenant en plus en public… je ne crois pas que l'un vaille mieux qui l'autre. Comme quoi le Libre peut malheureusement gravement déraper quand de certaines sommes d'argent sont en jeu.
Mais ma question reste la même: Pourquoi ne sont-ils pas exploités (au lieu de l'objet) pour construire les discutions sur ces ID et avec des objets distincts plutôt que de répéter N fois le même message?
Parce que l'interopérabilité ça ne te permet pas d'avoir un « avantage compétitif »… mieux vaut réinventer la roue avec des sémantiques légèrement différentes, de manière obfusquée !
Il y a donc encore des évolutions possible pour les clients de messagerie.
C'est sûr. Après, là on parle d'évolution pour quelques geeks qui utilisent de « bons » clients (enfin, qui inter-opèrent bien quoi ; je ne parle pas de l'UI qui est justement le problème). Les « autres » (soit 99,9%) resteront malheureusement assez stagnant.
ou des 5 qu'il cherche pour faire du remplissage avec pour seule condition d'être une femme parce qu'il n'y a pas assez de militantes?
Dans le dernier cas, ça ne me dérange pas…
Là, c'est sûr que tu vas vachement attirer les candidates ! Au cas où certains pensaient que le PP en avait quelque chose à faire de la parité…
Ce qui m'embête, perso, c'est que le mec en question est l'auteur principal de la RFC définissant l'extension heartbeat : https://tools.ietf.org/html/rfc6520
Comme j'ai lu sur slashdot, « si même le mec qui a écrit la RFC n'est pas capable de l'implémenter correctement… ».
(après, perso, le code a l'air tellement crade que je le crois quand il plaide l'incompétence)
Posté par benoar .
En réponse à la dépêche Firefox 28.
Évalué à 3.
Ca fait longtemps que les plugins dont Flash sont dans un processus separe (plugin-container).
Heu… à l'époque (ça fait quelque temps, certes), on attendait cette feature, mais j'avais entendu d'une personne de Mozilla directement que ça avait été repoussé et que ça serait sûrement abandonné car trop galère.
Si Firefox plante, c'est probablement un bug dans Firefox lui-meme: soit dans le coeur, soit a cause d'une extension qui part en vrille et que Firefox ne sait pas rattraper.
Bah moi j'ai jamais, du tout, vu Firefox planter, et pourtant j'utilise un certain nombre d'extensions. Je me demande donc bien comment on peut dire qu'il plante, à moins que j'ai vraiment un setup spécial…?
Normalement, si c'est Flash qui plante tu as la surface du player qui affiche un message d'erreur et il suffit de recharger la page. C'est facilement testable en tuant plugin-container pendant qu'on regarde une video sur YouTube par exemple.
Bah, peut-être qu'il sait gérer un processus tué, mais à priori pour un truc qui plante bien grassement comme Flash, il n'a pas l'air d'aimer.
Posté par benoar .
En réponse à la dépêche Firefox 28.
Évalué à 6.
Je pense que ce qui fait le plus planter Firefox, c'est Flash…
+1000. Je n'ai pas vu Firefox planter depuis des lustres, et pourtant je teste pas mal de version différentes (les stables, certes). Tous les gens qui me parlent de plantage, à chaque fois on trouve que le dénominateur commun c'est Flash…
Non, je parle bien d'une partie du SSD (quelques Go) qui sert à aller très très vite, et il y a une copie en arrière plan vers la partie "lente", et du coup si par exemple si la partie rapide est de 1 Go tu fais une écriture de 900 Mo et tu trouves que ça déchires, tu fais une écriture de 2 Go les perfs tombent.
Ah, étrange, je me renseigne pas mal sur les SSD mais je n'ai jamais entendu parler de ça. Les SSD ont un cache sous forme de RAM, mais qui n'atteint pas le Go, mais plutôt la centaine de Mo, et qui sert à « aller vite » pendant que l'écriture se fait sur la Flash… mais je suppose que tu ne parles pas de ça.
Bref, ce qu'il faut retenir est les constructeurs ont des tonnes d'idées pour avoir un bon rapport perfs/coût, et que quand on benche il faut de nos jours avec les SSD le faire en conditions réelles de chez réelles tellement le moindre petit paramètre qui change peut changer le résultat d'une compétition de SSD, et qu'un Bench synthétique ne peut donner qu'une idée partielle de la partie la plus rapide du SSD, bref juste donner une direction.
Zut, je n'arrive pas à trouver des liens rapidos de si bon matin, mais des SSD on une partie "rapide" (SLC chère) et une partie "lente" (MLC moins chère), et le contrôleur joue avec les deux, du coup si tu ne touche pas la limite de la SLC (si tu fais des perfs que de manière ponctuelle) les perfs sont bonnes et sinon au bout de quelques secondes les perfs peuvent tomber.
Ça n'est pas qu'il y a une « partie » SLC, c'est que tant que ton disque n'est qu'à moitié utilisé, le SSD utilise seulement 2 niveaux par cellule, pour coder un bit, alors que quand tu dépasses cette limite, il se met à utiliser 4 niveaux par cellule, pour pouvoir coder 2 bits (le « Multi » de MLC c'est pour dire que tu codes plus d'un bit par cellule ; en général 2 bits, mais aujourd'hui on a aussi de la TLC qui est de la MLC à 3 bits/cellule). Le truc, c'est que pour écrire/lire une cellule à deux niveaux, tu mets moins de temps car tu peux y aller plus « à l'arrache » en ayant que deux « zones » de reconnaissance de l'état de charge de ta cellule. Quand tu passe à quatre niveaux, il faut être plus fin, alors ça met plus de temps, et tes perfs tombent.
Que sans détails ni sur le hard, ni sur la conf soft, ça ne sert pas à grand chose à ceux qui s'intéressent à la technique, à part pour montrer que tu as la plus grosse…
C'est marrant comme tu as l'air de prendre le contrepoint de ce que je dis alors qu'en gros je suis d'accord avec toi…
Pour moi c'est surtout que les gens veulent tout avoir : le beurre et l'argent du beurre.
Ça c'est clair que c'est un problème : il faut toujours avoir une sorte d'incitation à payer, sinon s'il y a moyen de l'avoir gratuit, la majorité va le prendre comme ça.
Si le producteur de contenu est persuadé que ses productions sont assez bien pour être rémunérés, il peut faire payer la consultation. La publicité n'est pas obligatoire et ne l'a jamais été. Ni le fait d'être rémunéré par ailleurs.
Je suis tout à fait pour ça. Sauf qu'aujourd'hui, faire payer pour un article de blog par exemple, c'est une telle gageure pour un prix si faible que ça ne vaut pas le coup, c-à-d que personne n'est prêt à le faire. Plusieurs systèmes s'y sont essayés (Flattr entre autres) mais n'ont pas une popularité fulgurante… C'est un gros manque pour ce que modèle du paiement à « l'achat », qui est en gros le modèle classique que tout le monde connaît et utilise tous les jours : il nous faut un moyen de paiement pour ça.
Ça ressemble à un faux chantage dit comme ça, et personnellement je n'y suis pas favorable. La publicité a un coût mais invisible, car tu paies avec quelque chose de non papable qui est ta vie privée. Et ce coût peut être dans certains cas assez terrible.
Complètement d'accord qu'on paye ce que nous sortes tous les sites « gratuits », indirectement. Et c'est très dangereux. En gros, il faudrait juste une meilleure manière (plus directe) de rémunérer ceux qui sont financés par la publicité.
Pourtant l'information est payée aujourd'hui encore. Publicité, ventes de numéros, abonnements, subventions étatiques, etc.
Oui, enfin je parlais surtout du fait qu'aujourd'hui, beaucoup de monde consomme du « gratuit ».
Le problème est que la publicité entraîne une non neutralité du contenu : est-ce qu'un journaliste va faire un article peu élogieuse contre son principal sponsor même s'il le mérite ? Peu probable sinon il risque son poste, son salaire, …
Tu noteras que les journaux français sans publicités ont une meilleur image de qualité que les autres : Mediapart et le Canard Enchaîné et sont sans doute plus proche du véritable journalisme que les autres (bah oui, le journalisme d'investigation véritable est assez absent dans la concurrence où les dépêches AFP sont la base de leur travail).
Tout à fait.
Pour moi il y a un problème oui, et le problème vient directement du choix de rémunération et la publicité n'est pas garante de qualité…
Oui, mais d'un autre côté, quelle est l'alternative ? Je suis d'accord que pour un journal papier, je ne vois pas d'autres modèles que le paiement à l'exemplaire et je ne comprends pas qu'on accepte si facilement les « gratuits » (ou plutôt « prépayés ») papier. Par contre, sur Internet, où on a beaucoup moins le concept de journal « complet », où les choses se font plus à l'article, le paiement à l'unité est vraiment très difficile à mettre en place, du fait aussi de l'absence de proximité physique. Et du coup, la publicité est la réponse facile au financement. C'est à ce cercle vicieux qu'il faut trouver une issue.
Tant qu'un modèle économique stable et non basé sur la publicité ciblée n'apparaîtra pas, les technologies de traque auront toujours une longueur d'avance sur la majorité des citoyens.
Effectivement, je pense que ton constat est très vrai, même si je suis absolument contre trouver « acceptable » ou « pas si néfaste » de se faire cibler pour compenser financièrement le producteur de contenu.
La diminution du ciblage (car pour la suppression totale, on peut rêver) n'arrivera que quand on aura trouvé un moyen de rémunérer correctement les producteurs de contenu sur le Net. Ça passe aussi bien par un modèle économique viable qu'une méthode de paiement adaptée à des faibles montants, anonymes et virtuels. Et ça n'est pas une mince affaire.
Cette constatation ça me fait un peu penser à tous ces gens qui critiquent le journalisme aujourd'hui : tous les journaux sont « pourris », l'information est complètement orientée, etc. Mais qui paye encore son information quotidienne aujourd'hui ? Bah forcément, quand on ne la finance plus, il ne nous parvient que de la merde.
Oui enfin là tu parles d'un HTC, pas d'un Samsung ; les devs de Replicant parlaient bien de ce genre de téléphone, pas d'autres, d'où ma remarque sur le fait que ces Samsung étaient un peu les « moins pires ». Alors après dire « de toutes façons ils sont tous troués », et d'accuser la FSF de faire de la pub, c'est facile.
Sur certains telephones, le CPU baseband a access a la memoire du second CPU, dans d'autres cas c'est lui qui demarre le boot avant de passer la main au CPU secondaire qui va faire tourner Android.
Tiens, d'un coup c'est moins clair : arrête de balancer des rumeurs comme ça sans prouver. Les devs de replicant ont dit que les modems qu'on trouve sur ces téléphones sont justement plutôt « bons » pour la liberté dans le sens où ils n'ont pas accès à la RAM. Pour l'accès à la Flash, je n'en ai jamais entendu parler : où sont tes sources ? En attendant, tu FUD.
Bon, je n'ai pas énormément plus compris. Au début tu parles de remplacement mais après tu ne remplaces jamais rien, et puis tu parles de « fichier » pour tes fichiers différents, alors que j'ai identifié au moins deux types différents (ceux, d'une ligne, qui contiennent l'erreur — d'ailleurs, parler de « première ligne » pour un fichier d'une ligne ajoute à la confusion — et celui qui a une tables de correspondance des remplacements).
Ce que je vois, c'est que getline ne te renvoie qu'une ligne, donc oui forcément tu n'as que le premier match du grep/sed invoqué.
En passant, j'ai l'impression que ton but plus général, ça ressemble à une jointure SQL. Si tu veux commencer à faire de la manipulation de donnée un peu avancée, tu ferais peut-être mieux d'importer tout ça en SQL et de créer des requêtes adéquates. Ça sera même plus clair pour toi je pense, au lieu de jouer du shell et des fichiers (c'est bien pour un petit script qui fait une tâche simple, mais ça devient vite limitant).
Bon, j'ai moyennement compris ton problème, car les explications en français c'est moyen (« lancer plusieurs fois » : pour quelle raison ? avec quels arguments ? pour quel résultat ? ; tu as des fichiers d'une ligne, est-ce qu'ils correspondent à une « erreur » ? c'est quoi ces « erreurs » ?).
Par contre, je peux te dire que c'est contre-productif de faire un grep dans awk : awk a des fonctions intégrées pour ça. Si tu veux faire quelque chose quand une ligne match, fait :
/\^Chaine1/ { quelquechose }
Ensuite, si tu veux faire « simplement » du remplacement, un bon vieux sed marche bien. Ton fichier de chaînes, d'ailleurs, tu pourrais en faire un script sed :
Vu que personne n'a l'air d'avoir été regarder le code, voyons ce qu'il y a avec un rapide coup d'œil.
Tout d'abord, le driver fourni est une pile OpenGL ES1.1 et 2.0 pour Android 4 seulement. Elle a l'air entièrement maison, donc aucune réutilisation de Mesa ou autre code déjà libre. Elle fait un peu plus de 300 000 lignes (cf sloccount), dont plus de 80% de C, avec quand même 40 000 lignes d'assembleur (!). La majeure partie se trouve dans brcm_usrlib/.
Cette histoire d'assembleur m'intrigue. Quand on regarde de près (brcm_usrlib/dag/vmcsx/helpers/), ce sont des routines de traitement d'image (blit, mask, or/xor, transposition, flip, conversion yuv/rgb, etc dans vc_image/) ou des optimisations de routines « classique » (crc, génération d'aléa, statistiques, opérations mémoire pour vclib/) principalement écrites en utilisant des instructions NEON (instructions SIMD). On voit donc que ça permet d'avoir des routines rapides, mais pour l'instant on reste entièrement sur le CPU.
À propos de calcul « soft » (par opposé au GPU), on voit que l'OpenVG est codé entièrement sur le CPU également (vmcsx/middelware/khronos/vg/). Sinon, une grosse partie des autres « middleware » sont apparemment pour la gestion de shaders. Il y a également un compilateur de shaders.
Une grosse partie du code va dans l'interface avec le GPU (vmcsx/interface/), où ils réinventent un système d'IPC à leur sauce.
Niveau code, c'est moyen (des ifdef partout, pas de convention de codage) mais j'ai vu pire. Je ne connais pas le système de build d'Android, donc je ne me prononcerait pas sur la facilité de compilation.
Bref, une pile « standalone », qui ne réutilise rien de l'existant, qui a plein de choses spécifiques à cette puce (c'est normal pour un driver, mais là ça fait beaucoup), je ne pense pas que ça va intéresser grand monde, à part ceux qui ont des RPi et beaucoup de temps à y investir. Ils réinventent une grosse partie de Mesa, et ça n'est pas demain la veille à mon avis qu'on verra le support de cette puce à ce projet. À part peut-être les implémentations NEON qui pourraient éventuellement être intéressantes pour un moteur OpenGL ES software pour ARM, je ne vois pas grand chose à récupérer.
Je n'ai pas des masses regardé la doc, mais elle est assez « courte » (111 pages) pour une spécification. Je ne suis pas non plus un spécialiste des cartes graphiques, donc je ne sais pas si elle est bonne ou pas.
Donc voilà, c'est bien de sortir du code libre, mais certains codes ont plus d'intérêts que d'autres, en fonction de leur intégration à l'existant. Là, je ne vois pas beaucoup l'intérêt. Ce qui fait que je n'irai pas jusqu'à dire merci à Broadcom, surtout connaissant leur passif, même si on ne va pas non plus les dénigrer pour avoir sorti ce code.
et surtout que se mécanisme induit une dépendance entre http et un autre protocole (DNS).
Heu… je ne sais pas si tu appelles ça une « dépendance », mais depuis longtemps (HTTP 1.1 !) on doit inclure le header "Host". Ton protocole va donc t'afficher un contenu différent en fonction du nom utilisé, et ton IP seule ne sera pas suffisante pour faire fonctionner ton site correctement.
Ajouter un enregistrement SRV à consulter, ça n'est pas la mort : on le fait déjà avec le AAAA. Et l'argument que j'ai vu ailleurs que « ça va entraîner plein de latences à cause des indirections DNS » est débile car prenant exemple sur un cas tordu, qui sera exactement le même qu'aujourd'hui quand quelqu'un veut faire un enchaînement de CNAME bizarre.
Le RIPE s'adressait quand même pas mal à des admins réseaux, j'osais espérer qu'ils nous filent les vrais bonnes pratiques…
Oui c'est vrai, j'avais omis ce point.
Et ils conseillaient de faire du /64, même pour une interco de ce type. Certains avaient dit "euh oui mais bon, ça gâche quand même pas mal d'adresses !", ce à quoi le RIPE répondait "t'inquiètes pas, on a prévu méga méga méga large, c'est pas pour rien". C'est ce que j'ai l'impression de retrouver dans le pdf que j'ai linké d'ailleurs. Ce cas particulier avait bien été abordé, y compris dans de petits exercices.
Je pense que du coup, c'est que chacun a son avis et n'en démord pas. Le /127 pour un lien point-à-point a semble-t-il été populaire au début, puis a été déconseillé par la RFC 3627, puis a re-été « autorisé » par la RFC6164. Je pense que vu cet historique, le consensus n'est toujours pas complètement atteint :-)
Encore une fois, je suis d'accord au niveau du routage, IPv6 ne change rien, donc tout reste possible, mais j'avais cru comprendre que le consensus c'était au plus petit du /64 pour quoi que ce soit (autoconf ou point à point, qu'importe, malgré la perte d'adresses).
En tous cas, je n'ai pas dit que /127 était bien pour tous les liens point-à-point : je pense par exemple aux liens PPP des VPNs, où pouvoir faire du RFC 4941 (Privacy Extensions for SLAAC in IPv6) est utile. Bref, il faut adapter à chaque situation.
C'est logique si tu relis bien le message auquel tu réponds : les /64 c'est pour des subnets où tu accueilleras des machines qui font de l'autoconfiguration. Le /127 c'est pour le cas particulier des liaisons point à point, souvent entre deux routeurs. Le truc, c'est que si tu es un admin « lambda », tu n'as peut-être pas eu souvent l'occasion de rencontrer le deuxième cas. Je pense que c'est pour ça que dans les formations on insiste plutôt sur le premier, beaucoup plus courant.
Par exemple je travaille sur une grosse image en retouche et ça swappe. Manque de bol, mon disque est vieux et commence à avoir les secteurs qui s'affolent dans la zone du swap.
Est-ce que en sauvant mon travail je ne me retrouve pas avec une image corrompue ?
Je ne sais pas vraiment. J'avoue que ton exemple serait peut-être le contre-exemple pour ceux qui ne se soucient pas de la redondance du swap, mais perso ça me paraît tellement peut probable et est classé dans les cas « pas de chance » pour moi, que bon… ton ordi plante, tu as perdu ton image, point. Je n'ai pas le courage de me protéger de ça :-)
Je n'ai pas regardé en profondeur, mais en gros on a un support du frame buffer, de la communication entre la carte et le CPU, de la gestion de la mémoire… et c'est tout. C'est effectivement la base, ça permet d'afficher des images, cool. Mais niveau « driver », on attend la suite. Ils peuvent très bien garder le reste du driver fermé, et laisser cette partie ouverte : c'est celle la plus proche du kernel, la plus susceptible de changer avec le noyau, et qui demande donc le plus de boulot « chiant » : on laisse sa charge aux gentils contributeurs. Eux se réservent donc (pour l'instant) tout le reste, qui permet de réellement faire des choses intéressantes avec la carte. Bref, c'est mieux qu'avant, mais ça n'est pas la panacée.
[^] # Re: En pratique
Posté par benoar . En réponse au journal La diversité ou la complexité inutile ?. Évalué à 2.
Il y a un truc fait par le projet GNU qui existe depuis longtemps qui s'appelle les autotools et qui fait ça « très bien » depuis des lustres. Faire un .deb depuis un projet autotoolifié c'est très peu de boulot. Après, chacun a sa manière de haïr les autotools, mais bon… et aussi, n-ième standard, toussa…
[^] # Re: Intro
Posté par benoar . En réponse au journal Linagora vs BlueMind. Évalué à 7.
Effectivement, ça me semble complètement délirant ! Le commit est ici :
https://github.com/linagora/OBM/commit/a0a4b7b1e63cc92e190ac4010b7d5f1fb9cea2d7
Je pense que ça n'a rien à voir avec la condition de raison de la clause 7. Bref, on a deux acteurs qui dans un sens comme dans l'autre (puisque Blue Mind avait l'air, avant d'être revenu en arrière, de vouloir proposer des versions commerciales de logiciels libres) à des gens qui veulent abuser du Libre et se tirent là bourre commercialement, et maintenant en plus en public… je ne crois pas que l'un vaille mieux qui l'autre. Comme quoi le Libre peut malheureusement gravement déraper quand de certaines sommes d'argent sont en jeu.
[^] # Re: webmail
Posté par benoar . En réponse au journal Thunderbird : j'en peux plus ! Qui arrive à l'utiliser pour de vrai ? Quoi d'autre ?. Évalué à 2.
Parce que l'interopérabilité ça ne te permet pas d'avoir un « avantage compétitif »… mieux vaut réinventer la roue avec des sémantiques légèrement différentes, de manière obfusquée !
C'est sûr. Après, là on parle d'évolution pour quelques geeks qui utilisent de « bons » clients (enfin, qui inter-opèrent bien quoi ; je ne parle pas de l'UI qui est justement le problème). Les « autres » (soit 99,9%) resteront malheureusement assez stagnant.
[^] # Re: webmail
Posté par benoar . En réponse au journal Thunderbird : j'en peux plus ! Qui arrive à l'utiliser pour de vrai ? Quoi d'autre ?. Évalué à 4.
Voire le mettre dans un « standard pour l'ARPA » http://tools.ietf.org/html/rfc822#section-4.6
[^] # Re: Au nom de l'égalité…
Posté par benoar . En réponse au journal Le Parti Pirate cherche 5 femmes pour les Européennes avant le 21 avril. Évalué à 3.
Là, c'est sûr que tu vas vachement attirer les candidates ! Au cas où certains pensaient que le PP en avait quelque chose à faire de la parité…
[^] # Re: un effet Snowden?
Posté par benoar . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 3.
Ce qui m'embête, perso, c'est que le mec en question est l'auteur principal de la RFC définissant l'extension heartbeat :
https://tools.ietf.org/html/rfc6520
Comme j'ai lu sur slashdot, « si même le mec qui a écrit la RFC n'est pas capable de l'implémenter correctement… ».
(après, perso, le code a l'air tellement crade que je le crois quand il plaide l'incompétence)
[^] # Re: onglets bien ronds
Posté par benoar . En réponse à la dépêche Firefox 28. Évalué à 3.
Heu… à l'époque (ça fait quelque temps, certes), on attendait cette feature, mais j'avais entendu d'une personne de Mozilla directement que ça avait été repoussé et que ça serait sûrement abandonné car trop galère.
Bah moi j'ai jamais, du tout, vu Firefox planter, et pourtant j'utilise un certain nombre d'extensions. Je me demande donc bien comment on peut dire qu'il plante, à moins que j'ai vraiment un setup spécial…?
Bah, peut-être qu'il sait gérer un processus tué, mais à priori pour un truc qui plante bien grassement comme Flash, il n'a pas l'air d'aimer.
[^] # Re: onglets bien ronds
Posté par benoar . En réponse à la dépêche Firefox 28. Évalué à 6.
+1000. Je n'ai pas vu Firefox planter depuis des lustres, et pourtant je teste pas mal de version différentes (les stables, certes). Tous les gens qui me parlent de plantage, à chaque fois on trouve que le dénominateur commun c'est Flash…
[^] # Re: Ok voici plus de précisions
Posté par benoar . En réponse au journal Linux Centos et disque SSD. Évalué à 2.
Ah, étrange, je me renseigne pas mal sur les SSD mais je n'ai jamais entendu parler de ça. Les SSD ont un cache sous forme de RAM, mais qui n'atteint pas le Go, mais plutôt la centaine de Mo, et qui sert à « aller vite » pendant que l'écriture se fait sur la Flash… mais je suppose que tu ne parles pas de ça.
Tout à fait.
[^] # Re: Ok voici plus de précisions
Posté par benoar . En réponse au journal Linux Centos et disque SSD. Évalué à 1.
Ça n'est pas qu'il y a une « partie » SLC, c'est que tant que ton disque n'est qu'à moitié utilisé, le SSD utilise seulement 2 niveaux par cellule, pour coder un bit, alors que quand tu dépasses cette limite, il se met à utiliser 4 niveaux par cellule, pour pouvoir coder 2 bits (le « Multi » de MLC c'est pour dire que tu codes plus d'un bit par cellule ; en général 2 bits, mais aujourd'hui on a aussi de la TLC qui est de la MLC à 3 bits/cellule). Le truc, c'est que pour écrire/lire une cellule à deux niveaux, tu mets moins de temps car tu peux y aller plus « à l'arrache » en ayant que deux « zones » de reconnaissance de l'état de charge de ta cellule. Quand tu passe à quatre niveaux, il faut être plus fin, alors ça met plus de temps, et tes perfs tombent.
Je n'ai pas de lien précis mais ça se trouve sur le très bon http://www.hardware.fr/.
# Et les détails ?
Posté par benoar . En réponse au journal Linux Centos et disque SSD. Évalué à 4.
Que sans détails ni sur le hard, ni sur la conf soft, ça ne sert pas à grand chose à ceux qui s'intéressent à la technique, à part pour montrer que tu as la plus grosse…
[^] # Re: Problème de modèle économique
Posté par benoar . En réponse au journal Comment réduire les attaques à notre vie privée sur le web. Évalué à 3.
C'est marrant comme tu as l'air de prendre le contrepoint de ce que je dis alors qu'en gros je suis d'accord avec toi…
Ça c'est clair que c'est un problème : il faut toujours avoir une sorte d'incitation à payer, sinon s'il y a moyen de l'avoir gratuit, la majorité va le prendre comme ça.
Je suis tout à fait pour ça. Sauf qu'aujourd'hui, faire payer pour un article de blog par exemple, c'est une telle gageure pour un prix si faible que ça ne vaut pas le coup, c-à-d que personne n'est prêt à le faire. Plusieurs systèmes s'y sont essayés (Flattr entre autres) mais n'ont pas une popularité fulgurante… C'est un gros manque pour ce que modèle du paiement à « l'achat », qui est en gros le modèle classique que tout le monde connaît et utilise tous les jours : il nous faut un moyen de paiement pour ça.
Complètement d'accord qu'on paye ce que nous sortes tous les sites « gratuits », indirectement. Et c'est très dangereux. En gros, il faudrait juste une meilleure manière (plus directe) de rémunérer ceux qui sont financés par la publicité.
Oui, enfin je parlais surtout du fait qu'aujourd'hui, beaucoup de monde consomme du « gratuit ».
Tout à fait.
Oui, mais d'un autre côté, quelle est l'alternative ? Je suis d'accord que pour un journal papier, je ne vois pas d'autres modèles que le paiement à l'exemplaire et je ne comprends pas qu'on accepte si facilement les « gratuits » (ou plutôt « prépayés ») papier. Par contre, sur Internet, où on a beaucoup moins le concept de journal « complet », où les choses se font plus à l'article, le paiement à l'unité est vraiment très difficile à mettre en place, du fait aussi de l'absence de proximité physique. Et du coup, la publicité est la réponse facile au financement. C'est à ce cercle vicieux qu'il faut trouver une issue.
[^] # Re: Problème de modèle économique
Posté par benoar . En réponse au journal Comment réduire les attaques à notre vie privée sur le web. Évalué à 4.
Effectivement, je pense que ton constat est très vrai, même si je suis absolument contre trouver « acceptable » ou « pas si néfaste » de se faire cibler pour compenser financièrement le producteur de contenu.
La diminution du ciblage (car pour la suppression totale, on peut rêver) n'arrivera que quand on aura trouvé un moyen de rémunérer correctement les producteurs de contenu sur le Net. Ça passe aussi bien par un modèle économique viable qu'une méthode de paiement adaptée à des faibles montants, anonymes et virtuels. Et ça n'est pas une mince affaire.
Cette constatation ça me fait un peu penser à tous ces gens qui critiquent le journalisme aujourd'hui : tous les journaux sont « pourris », l'information est complètement orientée, etc. Mais qui paye encore son information quotidienne aujourd'hui ? Bah forcément, quand on ne la finance plus, il ne nous parvient que de la merde.
Bref, oui, l'argent est le nerf de la guerre.
[^] # Re: Belle campagne de com' de la FSF
Posté par benoar . En réponse au journal Porte dérobée sur Samsung Galaxy - Projet Replicant. Évalué à 1.
Merci, je n'avais pas vu pour celui-là ; ça n'était pas précisé dans l'annonce ni dans la page sur la faille.
Oui enfin là tu parles d'un HTC, pas d'un Samsung ; les devs de Replicant parlaient bien de ce genre de téléphone, pas d'autres, d'où ma remarque sur le fait que ces Samsung étaient un peu les « moins pires ». Alors après dire « de toutes façons ils sont tous troués », et d'accuser la FSF de faire de la pub, c'est facile.
[^] # Re: Belle campagne de com' de la FSF
Posté par benoar . En réponse au journal Porte dérobée sur Samsung Galaxy - Projet Replicant. Évalué à 1.
Tiens, d'un coup c'est moins clair : arrête de balancer des rumeurs comme ça sans prouver. Les devs de replicant ont dit que les modems qu'on trouve sur ces téléphones sont justement plutôt « bons » pour la liberté dans le sens où ils n'ont pas accès à la RAM. Pour l'accès à la Flash, je n'en ai jamais entendu parler : où sont tes sources ? En attendant, tu FUD.
# Faut arrêter de jouer avec /etc/hosts
Posté par benoar . En réponse au journal Toi aussi installe ton propre linuxfr en trois lignes de bash... et contribue!. Évalué à 7.
Ça fait un bout de temps qu'on a inventé quelque chose de plus moderne : mDNS.
Donc, dans la VM on :
puis il ne restera qu'à se diriger directement vers "dlfp-dev.local" dans son navigateur, dans son ssh, dans son ping, dans son…
[^] # Re: process séparé ?
Posté par benoar . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 4.
On peut même mettre une boucle sur un variable qu'on changera avec le debuggeur :
Tu verras ton process apparaître lors de la requête, tu t'attaches dessus, tu fais :
(j'ai vu cette technique dans OpenL2TP)
[^] # Re: Besoin de plus de contexte et de clarté
Posté par benoar . En réponse au message Comportement GREP différent dans le shell et dans un script. Évalué à 1.
Bon, je n'ai pas énormément plus compris. Au début tu parles de remplacement mais après tu ne remplaces jamais rien, et puis tu parles de « fichier » pour tes fichiers différents, alors que j'ai identifié au moins deux types différents (ceux, d'une ligne, qui contiennent l'erreur — d'ailleurs, parler de « première ligne » pour un fichier d'une ligne ajoute à la confusion — et celui qui a une tables de correspondance des remplacements).
Ce que je vois, c'est que getline ne te renvoie qu'une ligne, donc oui forcément tu n'as que le premier match du grep/sed invoqué.
En passant, j'ai l'impression que ton but plus général, ça ressemble à une jointure SQL. Si tu veux commencer à faire de la manipulation de donnée un peu avancée, tu ferais peut-être mieux d'importer tout ça en SQL et de créer des requêtes adéquates. Ça sera même plus clair pour toi je pense, au lieu de jouer du shell et des fichiers (c'est bien pour un petit script qui fait une tâche simple, mais ça devient vite limitant).
Bonne chance.
# Besoin de plus de contexte et de clarté
Posté par benoar . En réponse au message Comportement GREP différent dans le shell et dans un script. Évalué à 3.
Bon, j'ai moyennement compris ton problème, car les explications en français c'est moyen (« lancer plusieurs fois » : pour quelle raison ? avec quels arguments ? pour quel résultat ? ; tu as des fichiers d'une ligne, est-ce qu'ils correspondent à une « erreur » ? c'est quoi ces « erreurs » ?).
Par contre, je peux te dire que c'est contre-productif de faire un grep dans awk : awk a des fonctions intégrées pour ça. Si tu veux faire quelque chose quand une ligne match, fait :
Ensuite, si tu veux faire « simplement » du remplacement, un bon vieux sed marche bien. Ton fichier de chaînes, d'ailleurs, tu pourrais en faire un script sed :
Etc. Et si tu veux vraiment que ça soit un CSV avec point virgule, tu pourrais même l'écrire ainsi :
Et ton fichier tableur devient magiquement un script sed qui fait ce que tu veux.
# Regardons le code
Posté par benoar . En réponse au journal Donc maintenant Broadcom aime l'open source et les specs ouverte ?. Évalué à 10.
Vu que personne n'a l'air d'avoir été regarder le code, voyons ce qu'il y a avec un rapide coup d'œil.
Tout d'abord, le driver fourni est une pile OpenGL ES1.1 et 2.0 pour Android 4 seulement. Elle a l'air entièrement maison, donc aucune réutilisation de Mesa ou autre code déjà libre. Elle fait un peu plus de 300 000 lignes (cf sloccount), dont plus de 80% de C, avec quand même 40 000 lignes d'assembleur (!). La majeure partie se trouve dans brcm_usrlib/.
Cette histoire d'assembleur m'intrigue. Quand on regarde de près (brcm_usrlib/dag/vmcsx/helpers/), ce sont des routines de traitement d'image (blit, mask, or/xor, transposition, flip, conversion yuv/rgb, etc dans vc_image/) ou des optimisations de routines « classique » (crc, génération d'aléa, statistiques, opérations mémoire pour vclib/) principalement écrites en utilisant des instructions NEON (instructions SIMD). On voit donc que ça permet d'avoir des routines rapides, mais pour l'instant on reste entièrement sur le CPU.
À propos de calcul « soft » (par opposé au GPU), on voit que l'OpenVG est codé entièrement sur le CPU également (vmcsx/middelware/khronos/vg/). Sinon, une grosse partie des autres « middleware » sont apparemment pour la gestion de shaders. Il y a également un compilateur de shaders.
Une grosse partie du code va dans l'interface avec le GPU (vmcsx/interface/), où ils réinventent un système d'IPC à leur sauce.
Niveau code, c'est moyen (des ifdef partout, pas de convention de codage) mais j'ai vu pire. Je ne connais pas le système de build d'Android, donc je ne me prononcerait pas sur la facilité de compilation.
Bref, une pile « standalone », qui ne réutilise rien de l'existant, qui a plein de choses spécifiques à cette puce (c'est normal pour un driver, mais là ça fait beaucoup), je ne pense pas que ça va intéresser grand monde, à part ceux qui ont des RPi et beaucoup de temps à y investir. Ils réinventent une grosse partie de Mesa, et ça n'est pas demain la veille à mon avis qu'on verra le support de cette puce à ce projet. À part peut-être les implémentations NEON qui pourraient éventuellement être intéressantes pour un moteur OpenGL ES software pour ARM, je ne vois pas grand chose à récupérer.
Je n'ai pas des masses regardé la doc, mais elle est assez « courte » (111 pages) pour une spécification. Je ne suis pas non plus un spécialiste des cartes graphiques, donc je ne sais pas si elle est bonne ou pas.
Donc voilà, c'est bien de sortir du code libre, mais certains codes ont plus d'intérêts que d'autres, en fonction de leur intégration à l'existant. Là, je ne vois pas beaucoup l'intérêt. Ce qui fait que je n'irai pas jusqu'à dire merci à Broadcom, surtout connaissant leur passif, même si on ne va pas non plus les dénigrer pour avoir sorti ce code.
[^] # Re: SRV
Posté par benoar . En réponse au journal HTTP2, le protocole écrit comme une loi américaine. Évalué à 2.
Heu… je ne sais pas si tu appelles ça une « dépendance », mais depuis longtemps (HTTP 1.1 !) on doit inclure le header "Host". Ton protocole va donc t'afficher un contenu différent en fonction du nom utilisé, et ton IP seule ne sera pas suffisante pour faire fonctionner ton site correctement.
Ajouter un enregistrement SRV à consulter, ça n'est pas la mort : on le fait déjà avec le AAAA. Et l'argument que j'ai vu ailleurs que « ça va entraîner plein de latences à cause des indirections DNS » est débile car prenant exemple sur un cas tordu, qui sera exactement le même qu'aujourd'hui quand quelqu'un veut faire un enchaînement de CNAME bizarre.
[^] # Re: Refaire la config
Posté par benoar . En réponse au journal L'apocalypse arrive. Évalué à 2.
Oui c'est vrai, j'avais omis ce point.
Je pense que du coup, c'est que chacun a son avis et n'en démord pas. Le /127 pour un lien point-à-point a semble-t-il été populaire au début, puis a été déconseillé par la RFC 3627, puis a re-été « autorisé » par la RFC6164. Je pense que vu cet historique, le consensus n'est toujours pas complètement atteint :-)
En tous cas, je n'ai pas dit que /127 était bien pour tous les liens point-à-point : je pense par exemple aux liens PPP des VPNs, où pouvoir faire du RFC 4941 (Privacy Extensions for SLAAC in IPv6) est utile. Bref, il faut adapter à chaque situation.
[^] # Re: Refaire la config
Posté par benoar . En réponse au journal L'apocalypse arrive. Évalué à 2.
C'est logique si tu relis bien le message auquel tu réponds : les /64 c'est pour des subnets où tu accueilleras des machines qui font de l'autoconfiguration. Le /127 c'est pour le cas particulier des liaisons point à point, souvent entre deux routeurs. Le truc, c'est que si tu es un admin « lambda », tu n'as peut-être pas eu souvent l'occasion de rencontrer le deuxième cas. Je pense que c'est pour ça que dans les formations on insiste plutôt sur le premier, beaucoup plus courant.
[^] # Re: Suggestions
Posté par benoar . En réponse au message RAID1 en général et BTRFS en particulier. Évalué à 2.
Je ne sais pas vraiment. J'avoue que ton exemple serait peut-être le contre-exemple pour ceux qui ne se soucient pas de la redondance du swap, mais perso ça me paraît tellement peut probable et est classé dans les cas « pas de chance » pour moi, que bon… ton ordi plante, tu as perdu ton image, point. Je n'ai pas le courage de me protéger de ça :-)
# C'est encore minime
Posté par benoar . En réponse au journal You're talking about a revolution. Évalué à 7.
Je n'ai pas regardé en profondeur, mais en gros on a un support du frame buffer, de la communication entre la carte et le CPU, de la gestion de la mémoire… et c'est tout. C'est effectivement la base, ça permet d'afficher des images, cool. Mais niveau « driver », on attend la suite. Ils peuvent très bien garder le reste du driver fermé, et laisser cette partie ouverte : c'est celle la plus proche du kernel, la plus susceptible de changer avec le noyau, et qui demande donc le plus de boulot « chiant » : on laisse sa charge aux gentils contributeurs. Eux se réservent donc (pour l'instant) tout le reste, qui permet de réellement faire des choses intéressantes avec la carte. Bref, c'est mieux qu'avant, mais ça n'est pas la panacée.