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.
Quels cookies sont exemptés de consentement ?
[…]
Ce sont les cookies ayant pour finalité exclusive de permettre, ou de faciliter la communication par voie électronique et les cookies strictement nécessaires à la fourniture d'un service expressément demandé par l'utilisateur.
C'est pour ça que vous voyez de plus en plus de sites signaler la création de cookies (tout du moins, ça fait quelques mois que je vois fleurir ces popups), les sites le faisant souvent pour des raisons non-strictement nécessaires : car c'est une transposition d'une directive européenne qui va peut-être commencer à être mieux appliquée.
Effectivement, très dommage pour un site qui dénonce le traçage.
Ok pour le swap. Je suis aussi en train de tester ZFS et celui-ci permet d'avoir le swap « à l'intérieur ». Je ne suis pas sûr que cela marche très bien (je n'ai pas trouvé beaucoup de retour) et il n'est déjà pas compatible avec l'hibernation. Mais c'est déjà ça.
À noter que cette histoire de swap résistant à la mort d'un disque, c'est uniquement si tu ne supportes pas que ta machine plante dans ce cas. Ça n'a rien à voir avec les pertes de données classiques engendrées par une perte de disque sans RAID. Moi, sur mes machines persos, je tolère des plantages / reboot sauvages (car c'est très rare) : ça ne m'a jamais rien fait perdre de grave. Si tu supportes un reboot (et encore, c'est pas forcé que ça tombe aussi mal) au moment de la perte d'un disque, te prends pas la tête et mes des swaps sur tes deux disques (ou juste un seul, pour diviser les chances par deux…) ; c'est ce que je fais perso. Je sais que le RAID1 c'est pour la continuité, mais c'est déjà pas mal d'avoir juste à rebooter sans se soucier du disque mort en attendant de le remplacer (et au moment du remplacement, ça nécessitera encore un reboot, alors… — oui, je parle de matos standard, pas de « l'entreprise » avec hotswap et tout le bordel).
Pour la première question, effectivement le swap en dehors c'est risqué, mais le swap « à l'intérieur » c'est pas non plus la panacée… Bref, pas de solution miracle, ou alors passer à du device mapper classique (je suppose que tu veux passer à btrfs pour éviter ça).
Je te conseillerais par contre, pour plus de facilité, de ne pas séparer / de /home complètement, mais de faire tout dans une partition avec un subvolume pour /home ; ça sépare un peu les deux (niveau méta-données), sans être non plus aussi clair qu'avec deux partitions, mais ça t'évite le problème de répartition de l'espace (ils peuvent occuper autant qu'ils veulent tant qu'il y a de la place sur le volume ; tu peux jouer avec les quota après, si tu veux).
Pour la deuxième question, ça fait un bout de temps qu'on est passé aux UUID ou aux labels, hein… Ne référence jamais directement le nom de ton device, et ça roule : un utilitaire scan les disques pour trouver les partitions btrfs au démarrage. Un peu comme pour LVM. Sache sinon que tu peux utiliser indifféremment /dev/sda ou /dev/sdb dans toutes les commandes btrfs, ça ne change rien pour lui.
Est-ce que tu peux essayer de te remettre en question toi aussi des fois ? Ça éviterait de tourner en rond…
L'oppression n'est pas nié, pas du tout.
Ah, OK : donc il faudra « juste » dire « les femmes sont opprimées par les ho… des hommes blancs mais… des êtres souvent masculins et particulièrement à peau… heu, des cons, oui, ça c'est sûr, mais je ne peux pas l'exprimer autrement ». En quoi ça va faire avancer la cause de viser « les sexistes » sachant que 99% des mecs doivent sûrement se déclarer non-sexistes ? C'est la situation actuelle, et ça ne marche pas car beaucoup d'hommes sont sexistes mais le nient. Là tu vas tout de suite t'esclaffer que c'est le pompon, « on » t'explique ce que tu es, non mais ho, qui je suis pour te dire ça ? Bah, c'est la réalité, et pour en sortir, il n'y a pas d'autre moyen que de viser clairement « les hommes », même si une très petite proportion se sentira visée à tort. Une plus grande proportion se sachant non-sexiste (réellement) le comprendra et « laissera passer », car elle sait que ça ne les concerne pas. Et j'espère que les vrais sexistes se sentiront bien visés.
Une fois le constat fait, vers quoi on change ? Tous les hommes sont censé se suicider d'avoir oser se comporter de la sorte ?
Tu tombes dans le manichéen… tu sais, la vie n'est pas toute noire ou toute blanche, on peut réfléchir sur soi, se rendre compte lesquels de nos comportements sont bien ou pas, etc. Tu sais, quand je faisais trois catégories au paragraphe précédent, ça n'est bien sur pas aussi clair : il y a un gradient de comportements. Je me classe (mais qui je suis pour me permettre ?!) plutôt dans le côté non-sexiste, mais ça ne m'empêche pas régulièrement de me poser la question pour certains de mes comportements.
La proposition est de lutter contre le sexisme dans les 2 sens, c'est plus facile de justifier des interdits qui s'imposent à tous, que de le faire qu'à une seule catégorie de personne.
Oui. Moi par exemple je me bats régulièrement contre les femmes qui « tapent » les mecs (souvent pas méchamment, mais c'est parfois un peu violent). Mais je ne vais pas me poser en victime et comparer ça à ce que les femmes subissent régulièrement, qui est mille fois plus grave. Mais c'est ce que vous faites ; regarde l'exemple ridicule de Zenitram au dessus : parler d'homme blancs qui puent… et les mecs, vous êtes obligés de sortir des cas aussi nuls pour justifier votre cause ? C'est minable, ridicule, et insultant pour ceux qui se prennent réellement ces injures régulièrement, et en masse. Nomme sommes tous égaux dans l'idéal, et il faut tendre vers ça. La réalité, c'est que certains (égaux à moi, homme blanc) sont défavorisés lourdement : faisons quelque chose pour rééquilibrer ça, sans tomber dans l'égalitarisme débile.
D'ailleurs, le nom m'avait aussi fait fuir, cela faisait bien trop blague potache d'ado attardé.
Moi perso, weboob ne m'a jamais repoussé, et les icônes m'ont fait rire, même. Le truc, c'est que derrière, on voit qu'il y a d'authentiques sexistes, et ça ça me gêne.
Le fait est qu'il est plus facile de faire tout proprement en integrant toute la chaine que de diviser le tout en 25 projets differents qui n'auront pas autant de traction et en dispersant les forces.
C'est marrant, ya quelques temps on me balançait l'argument contraire : systemd est super modulaire, il est bien divisé, il y a plein d'outils « indépendants »… Mais en fait, quand on creuse, non, tout est intégré à tout, et on a beau avoir des commandes séparées, elles utilisent leurs conventions légèrement différentes d'Unix, leur format spécifique, etc. Mais bon, ça a été clairement annoncé par Lennart, donc au moins on ne peut pas lui reprocher de cacher ses ambitions.
Dernière critique en date sur laquelle je suis tombé : http://lists.busybox.net/pipermail/busybox/2014-January/080379.html
(de Denys Vlasenko, lead developer de busybox, qui est ironiquement aussi un truc « tout en un » mais qui essaye de le faire en respectant les standards Unix, lui).
Et c'est marrant ton argument sur la « traction » d'un projet unique, sans « disperser » les forces : le LL en général est quand même plutôt basé sur un ensemble de projets indépendants, ou en tous cas un ensemble de développeurs indépendants, qui mettent leur travail ensemble. Là, prendre tous les devs qui sont chez Red Hat (même si je sais que RH n'est pas une boîte comme les autres qui ne va pas complètement pouvoir imposer sa vue à tous les devs qu'elle embauche) pour bosser sur un truc unique qui va « révolutionner » le Libre, je trouve ça dangereux, au contraire. Je pense qu'une des réussites du Libre, c'est de faire travailler ensemble des gens qui ont des objectifs différents, mais qui s'en accommodent. Si on commence à avoir une armée de devs à la botte d'une seule boîte, aussi bienveillante soit-elle (en général j'aime bien tout ce que fait RH, j'avoue que systemd est un des seuls trucs qui me picote un peu), ça peut facilement partir en sucette par la suite.
Integrer ca aide clairement a faire bouger les choses, un seul projet dans lequel ameliorer les choses, impactant toutes les distributions moderne de linux, pas de probleme de synchronisation de version, …
On dirait le discours de Shutlleworth… Non, je pense qu'il est impossible d'arriver à synchroniser tout, et même si c'est moins efficace, c'est mieux comme ça. Un peu comme une démocratie est vachement moins « efficace » qu'une dictature : oui, il faut mettre tout le monde d'accord pour avancer, au lieu de juste écouter un mec, mais c'est pour le mieux de tous. Pour info, je « viens » plutôt du monde Debian, où le truc important ça n'est pas tant le code, mais la constitution (le mot n'est pas anodin).
C'est ceux qui codent qui font la direction, Redhat a certe un certain nombre de dev, mais ils n'ont pas le pouvoir d'imposer leur solution. De meme pour Ubuntu.
Oui, ceux qui codent font la direction, et RH a une bonne partie des devs systemd, udev, etc, il me semble. Ubuntu, eux, ils ont quelques mecs important mais j'ai toujours eu une impression de lacune technique globale, quand même : il ont débauchés quelques balèzes, mais globalement ça donne une résultat très bof, pas réfléchi. RH, au contraire, quand je vois leurs projets, je suis toujours assez impressionné. Là je bosse pas mal sur libvirt, et tu vois que c'est un putain de truc bien réfléchi. Pour parler du même domaine, tu vois rapidement qu'OpenStack c'est un gros bordel ; pourtant, tu as un paquet de monde qui bosse dessus. RH s'est « plié » commercialement à s'intégrer dans OpenStack, mais techniquement, tu vois bien qu'ils maîtrisent libvirt, et qu'ils font du OpenStack parce que ça marche commercialement, mais ils gardent la maîtrise technique de leurs outils.
C'était juste un exemple, mais c'était pour dire que chez RH, la domination des codeurs permet d'imposer leurs solutions car ils sont mieux « organisés », ou je ne sais pas trop pourquoi, mais en tous cas ils sont forts. Je connais peu d'autres boîtes qui sont capables de ça, c'est pour ça que d'un côté, je les admire, mais de l'autre (pour systemd), ils me font peur.
Il y a une raison pour que Systemd progresse bien plus vite et couvre bien plus de cas d'usage que Upstart…
Parce que ça a été architecturé et développé par des mecs plus balèzes, mieux organisés. Même si niveau expertise technique, je pense que Lennart part beaucoup trop sur l'approche « table rase ».
Dans ce cas, je t'annonce que c'est totalement contre productif. Mettre tout le monde dans le même panier, et leur coller une étiquette sur la tronche en espérant qu'il change, c'est juste du n'impotre quoi. La sociologie montre très bien l'effet des étiquettes: les gens s'y conforment !
Sache que je ne colle jamais cette étiquettes aux « hommes blancs », sauf quand ils se mettent à jouer les victimes. Car je sais bien que c'est contre-productif dans la plupart des cas.
Tu te trompes d'adversaire.
Tu n'es pas la cible principale des critiques sur le machisme, oui. Par contre, je combats la dilution, le FUD, la diversion que créent ceux qui chipottent sur le « non mais je ne lâcherais jamais sur le renommage sexiste de mon soft, c'est une question d'honneur pour tous les hommes opprimés de cette planète ! », par exemple. C'est juste dégueulasse, même si « dans l'absolu », il n'y a pas de problème. On n'est pas dans un monde absolu. Et je peux te dire que toutes les femmes (oui, je vais faire encore un peu de sexisme) à qui j'ai dit que ce genre de débat avait place ont tout de suite préféré me dire qu'elles ne viendraient jamais dans cette communauté, car elles connaissent trop bien les humiliations dont elles sont victimes dans la société tous les jours. Votre combat sur « l'égalité » qui nie la réalité de l'oppression fait fuir les femmes.
Du coup, comme un processus ne peut surveiller que son fils, il se passe quoi dans le cas d'un soft comme le dit couchdb qui fait pas forcément un exec à la fin ( ie, le cas très précis de couchdb avec l'option pour relancer automatiquement le soft quand il se gauffre, cf /usr/bin/couchdb ) ?
Soit le script fait le SIGSTOP mais il va faire ça avant que couchdb soit prêt, soit erl le fait, mais personne ne va le surveiller.
Je n'ai peut-être pas capté un truc, mais pourquoi ne fait-il pas le SIGSTOP après ? Le coup de ne pouvoir surveiller que son fils, c'est sans utiliser les cgroup, hors, systemd l'utilise justement. Et même, pourquoi n'exec-t-il pas erl ? Bon, il a peut-être des raisons, et le coup du SIGSTOP peut effectivement sembler bidouille dans ce cas.
Et on peut généraliser le cas avec apache, php-fpm. Du coup, le code passe de "je fait raise(sigstop) + un if" à "je mets en place un canal de comm entre le fils et moi pour que le fils me signal son état, et que moi ensuite je fasse un SIGSTOP pour signaler à mon propre père.
OK, merci de l'explication sur les désavantages, je comprends mieux. À la base, je disais juste que l'excuse de « le coup du SIGSTOP est pourri car upstart le fait mal » me semblait en légère. Je suis d'accord du coup que ça n'est pas forcément le mieux.
Je ne suis pas sur qu'il soit sage d'user d'un argument de ce genre sans avoir fait un minimum de vérification et vérifier avant de supposer.
Rho, c'était pas une attaque ad hominem, c'était juste pour dire que ta remarque « c'est super facile de rajouter une dépendance » ne sera peut-être pas acceptée par tous les développeurs : oui, quand tu connais, c'est plus ou moins facile, mais en général les devs upstream ont besoin de faire appel à des empaqueteurs aguerris pour les aider à gérer tout ce bordel. Ça n'est pas pour rien que tout le monde peste contre les autotools : ils ne sont pas facile à aborder. (je ne dis pas qu'ils sont mauvais, au contraire : je suis même en train d'écrire une doc sur mon expérience dessus)
Quant à ton nick, oui, je sais que tu n'es pas un débutant, je fréquente linuxfr depuis un bout de temps quand même… ne le prend pas personnellement.
Si il y a que ça, tu peux aussi prendre les fichiers .c et .h prévu pour ça depuis le code de systemd. Moi, je trouve ça dégeu, mais si upstream insiste à pas rajouter de lien, c'est son code.
J'espère que ça peut être aussi facile que tu le dis. Vu l'inter-dépendance de tous les morceaux de systemd, je me permets d'avoir un petit doute, mais comme je n'ai pas regardé, je ne protesterais pas plus que ça.
Encore une fois, il y a 2 logiciels dans tout debian qui supporte le dit protocole.
Ah ? Merde, j'aurais dû vérifier, je pensais que c'était plus courant /o\
2) rajouter le support sur les milliers de paquets en question 3) patcher la documentation des milliers de paquets.
Note que ces points deux et trois sont aussi valables avec systemd.
Ensuite, c'est pas comme si Debian avait déjà fait des milliers de patchs pour tout un tas de trucs ( GFDL et la DGSF, le portage sur le Hurd, le portage pour kfreebsd ). C'est pas comme si les packageurs de Fedora ou d'autres distros doivent régulièrement faire des patchs pour tel nouvelle version de gcc ou tel options de gcc, tel lib qui a été mise à jours et qui changent 2/3 trucs.
Oui, mais dans ce que tu cites, c'est souvent soit pour enlever des trucs, soit pour adapter du code existant. L'ajout de dépendance sur un autre logiciel, pas prévu au début pour le programme, ça rentre pour moi quand même dans une catégorie un peu plus pointue de travail et potentiellement d'emmerdes. Mais bon, si ça permet d'améliorer la gestion de démons du système, ça mettra peut-être plus de motivation dans le cœur des empaqueteurs…
Enfin, je continue à dire qu'il n'y a pas vraiment besoin de rajouter de protocole de notification pour la plupart des softs. Il y a plus d’intérêt à faire du on-demand avec les sockets par exemple.
Perso, je trouverais ça pratique avec des softs qui ont des comportements pas facile à gérer pour moi ; typiquement, qui offrent un socket de contrôle, mais qui est créé après que l'exécutable se soit démonisé. Typiquement, dans le monde réel, ça passe, mais en VM ça va tellement vite que mes scripts d'init doivent kludger (sleep…) pour que ça marche. C'est pour ça que si systemd prend bien, et que le travail colossal pour l'intégrer est fait, je trouverai ça bien au final.
Et à force d'avoir des "victimes" qui arrêtent pas de me dire que je fais partie du groupe à abattre et que je dois subir comme les autres de mon groupe, quitte à avoir les crachats des "victimes", autant faire comme les autres salauds (ben oui, sinon je suis un peu con de sûbir comme les autres les mauvais côté sans profiter des bons côtés).
Mon pauvre. Ta vie doit vraiment être un enfer.
Ici, on incite fortement les hommes blancs à etre des sexistes racistes, et tant que vous ne comprendrez pas cette conséquence de cette façon de jouer la victime contre le "groupe", vous ne comprendrez pas pourquoi les gens réagissent comme ça.
Je comprends que ça te fasse chier. Ça me fait un peu chier aussi. Mais c'est pour aller vers le « mieux ». Ne rien faire, comme tu le prônes, et rester impassiblement « égalitaire », c'est ne pas ouvrir les yeux sur comment l'Histoire évolue. C'est sûr que les 35h, les congés payés, le mariage homosexuel, la fin de l'esclavage, etc, on les a obtenu en demandant gentiment aux dominateurs d'être égalitaires.
Bref : comment créer ce que vous dites contre quoi vous battre.
Si tu le penses… Il y aura toujours des cons sexistes. Ils se « créent » « naturellement », pas besoin d'une soit-disant réaction aux féministes ou autres combattant contre le sexisme. Ça, c'est un fantasme que tu aimes bien t'imaginer. Ça te rend combattant d'une « bonne cause » : résistant à l'oppression féministe ! Ça c'est un combat original qui en jette !
Et tu ne pourras pas les changer tous les sexistes. Il y en a, par contre, qui le sont plus ou moins inconsciemment ; eux, on peut essayer de faire quelque chose. Mais si tu leur demande gentiment, ils ne comprennent rien. Alors il faut passer par d'autres moyens d'action.
-C'est dégueulasse de généraliser sur la couleur de peau ou le sexe.
-Il y a des cons et des gens bien dans toutes les catégories sociales.
Tout à fait.
-Mais bon, comme on a dit que "les hommes blancs" dominent la société, c'est ok si on généralise à mort, si on les insulte, si on a de bons gros préjugés sur sur eux,
Je trouve que tu exagères complètement. Comme dit Beurt, je ne vois pas d'insulte ici, et je n'ai pas de « préjugés » : j'ai réagi sur une phrase que tu as écrit, indépendamment de ta couleur et de ton sexe, même si tu l'as du coup indiqué ici.
et si ça dérange certains qu'on le dise, c'est bien fait pour leur gueule, parce que d'habitude c'est dans l'autre sens.
Ce n'est pas ça qu'on dit, c'est qu'en tant que faisant partie d'une classe dominante, se plaindre quand la balance est tellement déséquilibrée peut sembler insultant pour les autres. Et toi, en tant que faisant partie — involontairement, car tu n'as pas choisi ton sexe ni ta couleur de peau — de cette classe dominante, il te revient un peu d'essayer de casser ces préjugés, et le premier est de ne pas te poser en victime tellement c'est dégueulasse. Le deuxième sera de combattre les homme blancs dominants qui gagnent ce pouvoir en clivant ainsi, en essayant de combattre les clichés sexistes ou racistes, par exemple. Car ils gagnent ce pouvoir en utilisant ta couleur de peau et ton sexe, en les opposant aux autres.
Oui, tu n'as pas choisi ce combat, non, tu ne veux pas faire partie d'un camp, mais malheureusement des personnes qui ont les même caractéristiques que toi ont choisi de les utiliser comme « marqueur » d'une supériorité. Et si tu tiens tellement à l'égalité et à la non-discrimination, tu n'as pas vraiment d'autres choix que de les combattre. Et d'accepter que parfois, oui, certains vont malencontreusement faire des amalgames sur ta couleur ou ton sexe. J'espère qu'ils seront toujours minoritaires et que cela cessera quand la balance sera rétablie ; mais perso, déjà, je pense que ça n'arrivera pas de mon vivant…
quoi qu'on trouve quelques exceptions, comme quand Zenitram soulignait qu'on ne dit jamais "les femmes sont incapables de s'occuper des enfants"
Es-tu obligé de ressortir les saillies anecdotiques de ce connard ? Oui, il existe des déformations et des aberrations dans toutes les catégories de personnes, comme tu l'as noté plus haut. Cette dernière est anecdotique face aux autres aberrations paternalistes de notre société. Dans l'espèce de société idéale que Zorro s'imagine, tout est parfait et devrait être mathématiquement juste. Et bien quand tu vis l'injustice tout les jours et qu'un mec blanc vient te ramener à la gueule tes contradictions, oui, tu as envie de lui cracher à la gueule. Ça n'est pas comme ça qu'on fait avancer une cause, ça sert juste à énerver les gens sur des sujets qui ont de millions de fois moins de conséquences, histoire de faire partir de le débat en sucette, de faire perdre du temps aux gens, et de faire perdurer le status quo (c'est vrai ça, ne faisont rien puisque « naturellement » nous sommes tous égaux). C'est une technique rhétorique classique, approchant du FUD bien connu ici, et c'est une des raisons pour lesquelles des fois on a juste envie de dire péremptoirement à certaines personnes de se taire. C'est un gros troll, quoi.
Bah, l'implémentation d'upstrart est pourrie, et ? Tu relances au premier SIGSTOP uniquement, et c'est bon (tu vas me sortir le coup du mec qui SIGSTOP entre le lancement du programme et la fin de l'initialisation, je te sortirais qu'on ne demande pas une solution extrêmement parfaite ; c'est un truc pour aider ceux qui ne veulent pas dépendre de systemd).
Les logiciels marchent sans avoir besoin de signaler leur "readyness", le fait que personne ou presque n'implémente le protocole d'upstart est la preuve. Et rajouter l'appel en question , c'est surtout du taf sur les autootools que sur le code, c'est pas vraiment le plus compliqué.
Mouai, alors toi tu n'as pas du faire beaucoup d'empaquetage de logiciels. Quand tu fais réellement de l'intégration, ajouter une dépendance n'est pas du tout anodin. Après, je ne dis pas que c'est insurmontable, mais c'est ajouter des milliers de fois une charge qui pourrait être évitée (enfin, très réduite) si systemd l'implémentait.
Je ne comprends pas où tu veux en venir. La valeur d'1m² peut croitre sans limite. Le nombre d'action d'une entreprise est finis. Donc je vois pas où tu vois la différence.
La « valeur » du m² qui augmente, c'est sa valeur marchande. La valeur d'usage du m², elle sera à peu près toujours la même (en fonction de son utilisation, quand même), car on ne va pas se mettre à faire des maisons 10 fois plus grandes ou réussir à trouver du blé avec un rendement 10 fois supérieur demain. Ton entreprise, déjà son nombre d'action peut augmenter comme il veut, et le « bien » qu'elle peut faire n'est pas limité réellement par une quantité physique.
Comprends bien, je n'ai jamais dis que le bitcoin est bien, je dis juste qu'il ne faut pas lui attribué des tords qui ne sont pas de son fait. Tu es entrain de remettre en question notre économie dans son ensemble.
Je comprends que notre économie partage certaines caractéristiques avec le Bitcoin, mais quand même, ça faisait longtemps qu'on n'était pas « reparti à zéro » sur un bien spéculatif, et que tout le monde trouve ça « normal ».
Aujourd'hui tu es outré qu'un gars avec des bitcoins renfloue OpenBSD et qu'il ai le culot de dire d'où vient son argent, si ça avait était un quelconque trader tu en aurais fait de même ? (je me fous de la réponse, hein ? C'est juste qu'il faut que tu te pose la question)
Moi, je voyais plutôt immoral son acquisition en tant que miner. Je n'aime pas non plus les spéculateurs, mais miner pour spéculer… c'est très immoral.
Si tu as l'ambition de te battre contre ce type d'argent, il faut que tu sache qu'elle cartouche tirer sur quoi. Le bitcoin n'est qu'un détail, c'est la spéculation la clef. Pour un trader ou un robot trader le bitcoin, du blé ou autre.
Oui, je suis d'accord que ça n'est pas forcément le meilleur angle d'attaque dans l'absolu, et j'essaye de ne pas me concentrer sur ça. Mais c'était juste pour rappeler certaines considérations morales qui sont encore plus valables avec le Bitcoin.
Dans le cas de Google, ce qui est vendu, ce n'est pas toi mais l'exposition qu'offre une requete. D'ailleurs, je te conseille de faire un tour sur Google adwords pour te démystifier ca: quand tu poses une enchere publicitaire, tu ne le fais pas sur un profil d'utilisateur, mais bien sur une requete.
Faux. Ça s'appelle le “Real-time bidding”, ces informations sont négociées à chaque impression, en fonction de la localisation, de ton historique de navigation, de ton profile, etc. C'est comme le High Frequency Trading, mais c'est toi la marchandise qui est échangée à haute vitesse.
Rien de bien nouveau. La spéculation, faire du chiffre en étant le premier quelque part,… ça existait avant le bitcoin et ça existera après. Il y en a qui ont le culot d'acheter des terrains pas chère et qui les revendent avec une plus valu monstrueuse alors que leur seul mérite c'est de les avoir acheter assez tôt. Quand certains achètent des actions d'une boite pour 3 fois rien et qu'ils les revendent 5 ans après le triple du prix c'est le même principe.
Moi je vois quand même des choses différentes : le terrain, c'est un bien limité. L'entreprise, c'est quelque chose qui doit « créer de la valeur », à priori sans limite supérieure. Soit tu fais comme dans le Far West et chacun se sert jusqu'à ce qu'il n'y en ait plus, et tant pis pour ceux qui ne se sont pas servis, soit tu te dis au bout d'un moment qu'il faudrait quand même trouver des règles équitables, car sinon c'est trop vite le bordel et certains vont devenir « injustement » riches. Dans un autre commentaire, une moule parlait de « jalousie » : bien que pour certains c'est peut-être ça, le but au final c'est quand même, pour moi et sûrement d'autres, d'être équitable. Et donc, de ne pas participer à une chose si celle-ci n'est pas équitable.
Bitcoin n'est pas équitable (oui, comme plein d'autres « marchés » ou autres distributions de ressources) et donc je n'ai pas envie d'y participer. Je trouve ça dommage que d'autres le fassent, car ce faisant ils augmentent l'attrait global vers ce système inéquitable. Comme cette donation pour OpenBSD : le mec la fait en en parlant bien, histoire de crédibiliser cette monnaie. Donc, ceux qui y participent ne sont pas seulement « chanceux », ils entraînent également d'autres personnes dans ce cercle inéquitable en rendant ce système plus « respectable ». Après, dans l'absolu, oui, on ne va pas empêcher machin de faire ci ou ça, mais bon, les lois qu'on a obéissent à une certaine morale, généralement.
Tu peut évidement trouver que c'est mal, que spéculer sur une monnaie c'est mal (ça n'est pas lié qu'au bitcoin ça même les autres monnaies sont touchées), etc, mais ça n'est pas vraiment un problème de bitcoin c'est, je sais pas, le modèle ou le système économique qui est comme ça.
Oui, effectivement. Est-donc pour ça qu'il ne faut rien faire contre ? Commencer par ne pas promouvoir un tel système en n'y participant pas est déjà pas mal.
Quand on voit la réponse de Lennart https://bugzilla.redhat.com/show_bug.cgi?id=833105, on ne peut s'empêcher de voir la mauvaise foi de partout : il ignore l'utilisation de SIGSTOP seulement si un flag/variable d'environnement est mis, dit que ça peut être utilisé pour autre chose, mais là c'est dans le cas où le process l'utilise sur lui-même, il indique qu'il ne voit pas de différence entre appeler une fonction de la libc et introduire une dépendance à sa lib (il doit s'en foutre du boulot de mise à jour de tous les paquets, même les plus vieux/exotiques/etc…), … Alors que le rapport original demande juste une simple mesure pour être compatible optionnellement avec certains programmes !
Il est trop reulou. Techniquement, c'est à dire au niveau des capacités, je trouve que systemd bat de loin tous les autres. Ça serait la raison qui me fait le supporter. Mais entre son implémentation lourdingue, sa volonté de vouloir tout remplacer d'un coup (génial), l'intégration de tout dans systemd ce qui rend udev et d'autres utilitaires essentiels forcément dépendants de systemd sans toujours de bonne raisons, le « j'en n'ai rien à foutre des autres qui ne peuvent pas suivre », et l'ego démesuré de ce mec… c'est super chiant. Alors oui, je ne vois pas de solution aussi « bien » que la sienne, mais on sent tellement une sorte d'imposition de l'avis de RedHat sur un paquet de choses d'un coup, et que plein de monde va être largué parce que non compatible, que ça fait très peur.
# 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.
[^] # Re: Affichage du site NSA-observer
Posté par benoar . En réponse à la dépêche NSA-observer — quels sont les programmes de la NSA ?. Évalué à 3.
Ah merci pour l'info ; perso, le site qui oblige à avoir un cookie juste pour s'afficher, c'est poubelle direct.
En passant, le faire sans demander à l'utilisateur, c'est contraire à la loi, comme le rappellent les recommandations de la CNIL sur l'utilisation des cookies (publiées en décemble dernier) : http://www.cnil.fr/linstitution/actualite/article/article/recommandation-sur-les-cookies-quelles-obligations-pour-les-responsables-de-sites-quels-conseils/
C'est pour ça que vous voyez de plus en plus de sites signaler la création de cookies (tout du moins, ça fait quelques mois que je vois fleurir ces popups), les sites le faisant souvent pour des raisons non-strictement nécessaires : car c'est une transposition d'une directive européenne qui va peut-être commencer à être mieux appliquée.
Effectivement, très dommage pour un site qui dénonce le traçage.
[^] # Re: Suggestions
Posté par benoar . En réponse au message RAID1 en général et BTRFS en particulier. Évalué à 3.
À noter que cette histoire de swap résistant à la mort d'un disque, c'est uniquement si tu ne supportes pas que ta machine plante dans ce cas. Ça n'a rien à voir avec les pertes de données classiques engendrées par une perte de disque sans RAID. Moi, sur mes machines persos, je tolère des plantages / reboot sauvages (car c'est très rare) : ça ne m'a jamais rien fait perdre de grave. Si tu supportes un reboot (et encore, c'est pas forcé que ça tombe aussi mal) au moment de la perte d'un disque, te prends pas la tête et mes des swaps sur tes deux disques (ou juste un seul, pour diviser les chances par deux…) ; c'est ce que je fais perso. Je sais que le RAID1 c'est pour la continuité, mais c'est déjà pas mal d'avoir juste à rebooter sans se soucier du disque mort en attendant de le remplacer (et au moment du remplacement, ça nécessitera encore un reboot, alors… — oui, je parle de matos standard, pas de « l'entreprise » avec hotswap et tout le bordel).
# Suggestions
Posté par benoar . En réponse au message RAID1 en général et BTRFS en particulier. Évalué à 3.
Pour la première question, effectivement le swap en dehors c'est risqué, mais le swap « à l'intérieur » c'est pas non plus la panacée… Bref, pas de solution miracle, ou alors passer à du device mapper classique (je suppose que tu veux passer à btrfs pour éviter ça).
Je te conseillerais par contre, pour plus de facilité, de ne pas séparer / de /home complètement, mais de faire tout dans une partition avec un subvolume pour /home ; ça sépare un peu les deux (niveau méta-données), sans être non plus aussi clair qu'avec deux partitions, mais ça t'évite le problème de répartition de l'espace (ils peuvent occuper autant qu'ils veulent tant qu'il y a de la place sur le volume ; tu peux jouer avec les quota après, si tu veux).
Pour la deuxième question, ça fait un bout de temps qu'on est passé aux UUID ou aux labels, hein… Ne référence jamais directement le nom de ton device, et ça roule : un utilitaire scan les disques pour trouver les partitions btrfs au démarrage. Un peu comme pour LVM. Sache sinon que tu peux utiliser indifféremment /dev/sda ou /dev/sdb dans toutes les commandes btrfs, ça ne change rien pour lui.
[^] # Re: asshole detector
Posté par benoar . En réponse au journal La communauté Linuxfr n'a-t-elle plus rien (de technique) à dire ?. Évalué à 4.
Est-ce que tu peux essayer de te remettre en question toi aussi des fois ? Ça éviterait de tourner en rond…
Ah, OK : donc il faudra « juste » dire « les femmes sont opprimées par les ho… des hommes blancs mais… des êtres souvent masculins et particulièrement à peau… heu, des cons, oui, ça c'est sûr, mais je ne peux pas l'exprimer autrement ». En quoi ça va faire avancer la cause de viser « les sexistes » sachant que 99% des mecs doivent sûrement se déclarer non-sexistes ? C'est la situation actuelle, et ça ne marche pas car beaucoup d'hommes sont sexistes mais le nient. Là tu vas tout de suite t'esclaffer que c'est le pompon, « on » t'explique ce que tu es, non mais ho, qui je suis pour te dire ça ? Bah, c'est la réalité, et pour en sortir, il n'y a pas d'autre moyen que de viser clairement « les hommes », même si une très petite proportion se sentira visée à tort. Une plus grande proportion se sachant non-sexiste (réellement) le comprendra et « laissera passer », car elle sait que ça ne les concerne pas. Et j'espère que les vrais sexistes se sentiront bien visés.
Tu tombes dans le manichéen… tu sais, la vie n'est pas toute noire ou toute blanche, on peut réfléchir sur soi, se rendre compte lesquels de nos comportements sont bien ou pas, etc. Tu sais, quand je faisais trois catégories au paragraphe précédent, ça n'est bien sur pas aussi clair : il y a un gradient de comportements. Je me classe (mais qui je suis pour me permettre ?!) plutôt dans le côté non-sexiste, mais ça ne m'empêche pas régulièrement de me poser la question pour certains de mes comportements.
Oui. Moi par exemple je me bats régulièrement contre les femmes qui « tapent » les mecs (souvent pas méchamment, mais c'est parfois un peu violent). Mais je ne vais pas me poser en victime et comparer ça à ce que les femmes subissent régulièrement, qui est mille fois plus grave. Mais c'est ce que vous faites ; regarde l'exemple ridicule de Zenitram au dessus : parler d'homme blancs qui puent… et les mecs, vous êtes obligés de sortir des cas aussi nuls pour justifier votre cause ? C'est minable, ridicule, et insultant pour ceux qui se prennent réellement ces injures régulièrement, et en masse. Nomme sommes tous égaux dans l'idéal, et il faut tendre vers ça. La réalité, c'est que certains (égaux à moi, homme blanc) sont défavorisés lourdement : faisons quelque chose pour rééquilibrer ça, sans tomber dans l'égalitarisme débile.
Moi perso, weboob ne m'a jamais repoussé, et les icônes m'ont fait rire, même. Le truc, c'est que derrière, on voit qu'il y a d'authentiques sexistes, et ça ça me gêne.
[^] # Re: Mini précision, variable d'environnement
Posté par benoar . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 3.
C'est marrant, ya quelques temps on me balançait l'argument contraire : systemd est super modulaire, il est bien divisé, il y a plein d'outils « indépendants »… Mais en fait, quand on creuse, non, tout est intégré à tout, et on a beau avoir des commandes séparées, elles utilisent leurs conventions légèrement différentes d'Unix, leur format spécifique, etc. Mais bon, ça a été clairement annoncé par Lennart, donc au moins on ne peut pas lui reprocher de cacher ses ambitions.
Dernière critique en date sur laquelle je suis tombé : http://lists.busybox.net/pipermail/busybox/2014-January/080379.html
(de Denys Vlasenko, lead developer de busybox, qui est ironiquement aussi un truc « tout en un » mais qui essaye de le faire en respectant les standards Unix, lui).
Et c'est marrant ton argument sur la « traction » d'un projet unique, sans « disperser » les forces : le LL en général est quand même plutôt basé sur un ensemble de projets indépendants, ou en tous cas un ensemble de développeurs indépendants, qui mettent leur travail ensemble. Là, prendre tous les devs qui sont chez Red Hat (même si je sais que RH n'est pas une boîte comme les autres qui ne va pas complètement pouvoir imposer sa vue à tous les devs qu'elle embauche) pour bosser sur un truc unique qui va « révolutionner » le Libre, je trouve ça dangereux, au contraire. Je pense qu'une des réussites du Libre, c'est de faire travailler ensemble des gens qui ont des objectifs différents, mais qui s'en accommodent. Si on commence à avoir une armée de devs à la botte d'une seule boîte, aussi bienveillante soit-elle (en général j'aime bien tout ce que fait RH, j'avoue que systemd est un des seuls trucs qui me picote un peu), ça peut facilement partir en sucette par la suite.
On dirait le discours de Shutlleworth… Non, je pense qu'il est impossible d'arriver à synchroniser tout, et même si c'est moins efficace, c'est mieux comme ça. Un peu comme une démocratie est vachement moins « efficace » qu'une dictature : oui, il faut mettre tout le monde d'accord pour avancer, au lieu de juste écouter un mec, mais c'est pour le mieux de tous. Pour info, je « viens » plutôt du monde Debian, où le truc important ça n'est pas tant le code, mais la constitution (le mot n'est pas anodin).
Oui, ceux qui codent font la direction, et RH a une bonne partie des devs systemd, udev, etc, il me semble. Ubuntu, eux, ils ont quelques mecs important mais j'ai toujours eu une impression de lacune technique globale, quand même : il ont débauchés quelques balèzes, mais globalement ça donne une résultat très bof, pas réfléchi. RH, au contraire, quand je vois leurs projets, je suis toujours assez impressionné. Là je bosse pas mal sur libvirt, et tu vois que c'est un putain de truc bien réfléchi. Pour parler du même domaine, tu vois rapidement qu'OpenStack c'est un gros bordel ; pourtant, tu as un paquet de monde qui bosse dessus. RH s'est « plié » commercialement à s'intégrer dans OpenStack, mais techniquement, tu vois bien qu'ils maîtrisent libvirt, et qu'ils font du OpenStack parce que ça marche commercialement, mais ils gardent la maîtrise technique de leurs outils.
C'était juste un exemple, mais c'était pour dire que chez RH, la domination des codeurs permet d'imposer leurs solutions car ils sont mieux « organisés », ou je ne sais pas trop pourquoi, mais en tous cas ils sont forts. Je connais peu d'autres boîtes qui sont capables de ça, c'est pour ça que d'un côté, je les admire, mais de l'autre (pour systemd), ils me font peur.
Parce que ça a été architecturé et développé par des mecs plus balèzes, mieux organisés. Même si niveau expertise technique, je pense que Lennart part beaucoup trop sur l'approche « table rase ».
[^] # Re: asshole detector
Posté par benoar . En réponse au journal La communauté Linuxfr n'a-t-elle plus rien (de technique) à dire ?. Évalué à 3.
Sache que je ne colle jamais cette étiquettes aux « hommes blancs », sauf quand ils se mettent à jouer les victimes. Car je sais bien que c'est contre-productif dans la plupart des cas.
Tu n'es pas la cible principale des critiques sur le machisme, oui. Par contre, je combats la dilution, le FUD, la diversion que créent ceux qui chipottent sur le « non mais je ne lâcherais jamais sur le renommage sexiste de mon soft, c'est une question d'honneur pour tous les hommes opprimés de cette planète ! », par exemple. C'est juste dégueulasse, même si « dans l'absolu », il n'y a pas de problème. On n'est pas dans un monde absolu. Et je peux te dire que toutes les femmes (oui, je vais faire encore un peu de sexisme) à qui j'ai dit que ce genre de débat avait place ont tout de suite préféré me dire qu'elles ne viendraient jamais dans cette communauté, car elles connaissent trop bien les humiliations dont elles sont victimes dans la société tous les jours. Votre combat sur « l'égalité » qui nie la réalité de l'oppression fait fuir les femmes.
[^] # Re: Mini précision, variable d'environnement
Posté par benoar . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 3.
Je n'ai peut-être pas capté un truc, mais pourquoi ne fait-il pas le SIGSTOP après ? Le coup de ne pouvoir surveiller que son fils, c'est sans utiliser les cgroup, hors, systemd l'utilise justement. Et même, pourquoi n'exec-t-il pas erl ? Bon, il a peut-être des raisons, et le coup du SIGSTOP peut effectivement sembler bidouille dans ce cas.
OK, merci de l'explication sur les désavantages, je comprends mieux. À la base, je disais juste que l'excuse de « le coup du SIGSTOP est pourri car upstart le fait mal » me semblait en légère. Je suis d'accord du coup que ça n'est pas forcément le mieux.
Rho, c'était pas une attaque ad hominem, c'était juste pour dire que ta remarque « c'est super facile de rajouter une dépendance » ne sera peut-être pas acceptée par tous les développeurs : oui, quand tu connais, c'est plus ou moins facile, mais en général les devs upstream ont besoin de faire appel à des empaqueteurs aguerris pour les aider à gérer tout ce bordel. Ça n'est pas pour rien que tout le monde peste contre les autotools : ils ne sont pas facile à aborder. (je ne dis pas qu'ils sont mauvais, au contraire : je suis même en train d'écrire une doc sur mon expérience dessus)
Quant à ton nick, oui, je sais que tu n'es pas un débutant, je fréquente linuxfr depuis un bout de temps quand même… ne le prend pas personnellement.
J'espère que ça peut être aussi facile que tu le dis. Vu l'inter-dépendance de tous les morceaux de systemd, je me permets d'avoir un petit doute, mais comme je n'ai pas regardé, je ne protesterais pas plus que ça.
Ah ? Merde, j'aurais dû vérifier, je pensais que c'était plus courant /o\
Note que ces points deux et trois sont aussi valables avec systemd.
Oui, mais dans ce que tu cites, c'est souvent soit pour enlever des trucs, soit pour adapter du code existant. L'ajout de dépendance sur un autre logiciel, pas prévu au début pour le programme, ça rentre pour moi quand même dans une catégorie un peu plus pointue de travail et potentiellement d'emmerdes. Mais bon, si ça permet d'améliorer la gestion de démons du système, ça mettra peut-être plus de motivation dans le cœur des empaqueteurs…
Perso, je trouverais ça pratique avec des softs qui ont des comportements pas facile à gérer pour moi ; typiquement, qui offrent un socket de contrôle, mais qui est créé après que l'exécutable se soit démonisé. Typiquement, dans le monde réel, ça passe, mais en VM ça va tellement vite que mes scripts d'init doivent kludger (sleep…) pour que ça marche. C'est pour ça que si systemd prend bien, et que le travail colossal pour l'intégrer est fait, je trouverai ça bien au final.
[^] # Re: asshole detector
Posté par benoar . En réponse au journal La communauté Linuxfr n'a-t-elle plus rien (de technique) à dire ?. Évalué à 2.
Mon pauvre. Ta vie doit vraiment être un enfer.
Je comprends que ça te fasse chier. Ça me fait un peu chier aussi. Mais c'est pour aller vers le « mieux ». Ne rien faire, comme tu le prônes, et rester impassiblement « égalitaire », c'est ne pas ouvrir les yeux sur comment l'Histoire évolue. C'est sûr que les 35h, les congés payés, le mariage homosexuel, la fin de l'esclavage, etc, on les a obtenu en demandant gentiment aux dominateurs d'être égalitaires.
Si tu le penses… Il y aura toujours des cons sexistes. Ils se « créent » « naturellement », pas besoin d'une soit-disant réaction aux féministes ou autres combattant contre le sexisme. Ça, c'est un fantasme que tu aimes bien t'imaginer. Ça te rend combattant d'une « bonne cause » : résistant à l'oppression féministe ! Ça c'est un combat original qui en jette !
Et tu ne pourras pas les changer tous les sexistes. Il y en a, par contre, qui le sont plus ou moins inconsciemment ; eux, on peut essayer de faire quelque chose. Mais si tu leur demande gentiment, ils ne comprennent rien. Alors il faut passer par d'autres moyens d'action.
[^] # Re: asshole detector
Posté par benoar . En réponse au journal La communauté Linuxfr n'a-t-elle plus rien (de technique) à dire ?. Évalué à 0.
Tout à fait.
Je trouve que tu exagères complètement. Comme dit Beurt, je ne vois pas d'insulte ici, et je n'ai pas de « préjugés » : j'ai réagi sur une phrase que tu as écrit, indépendamment de ta couleur et de ton sexe, même si tu l'as du coup indiqué ici.
Ce n'est pas ça qu'on dit, c'est qu'en tant que faisant partie d'une classe dominante, se plaindre quand la balance est tellement déséquilibrée peut sembler insultant pour les autres. Et toi, en tant que faisant partie — involontairement, car tu n'as pas choisi ton sexe ni ta couleur de peau — de cette classe dominante, il te revient un peu d'essayer de casser ces préjugés, et le premier est de ne pas te poser en victime tellement c'est dégueulasse. Le deuxième sera de combattre les homme blancs dominants qui gagnent ce pouvoir en clivant ainsi, en essayant de combattre les clichés sexistes ou racistes, par exemple. Car ils gagnent ce pouvoir en utilisant ta couleur de peau et ton sexe, en les opposant aux autres.
Oui, tu n'as pas choisi ce combat, non, tu ne veux pas faire partie d'un camp, mais malheureusement des personnes qui ont les même caractéristiques que toi ont choisi de les utiliser comme « marqueur » d'une supériorité. Et si tu tiens tellement à l'égalité et à la non-discrimination, tu n'as pas vraiment d'autres choix que de les combattre. Et d'accepter que parfois, oui, certains vont malencontreusement faire des amalgames sur ta couleur ou ton sexe. J'espère qu'ils seront toujours minoritaires et que cela cessera quand la balance sera rétablie ; mais perso, déjà, je pense que ça n'arrivera pas de mon vivant…
Es-tu obligé de ressortir les saillies anecdotiques de ce connard ? Oui, il existe des déformations et des aberrations dans toutes les catégories de personnes, comme tu l'as noté plus haut. Cette dernière est anecdotique face aux autres aberrations paternalistes de notre société. Dans l'espèce de société idéale que Zorro s'imagine, tout est parfait et devrait être mathématiquement juste. Et bien quand tu vis l'injustice tout les jours et qu'un mec blanc vient te ramener à la gueule tes contradictions, oui, tu as envie de lui cracher à la gueule. Ça n'est pas comme ça qu'on fait avancer une cause, ça sert juste à énerver les gens sur des sujets qui ont de millions de fois moins de conséquences, histoire de faire partir de le débat en sucette, de faire perdre du temps aux gens, et de faire perdurer le status quo (c'est vrai ça, ne faisont rien puisque « naturellement » nous sommes tous égaux). C'est une technique rhétorique classique, approchant du FUD bien connu ici, et c'est une des raisons pour lesquelles des fois on a juste envie de dire péremptoirement à certaines personnes de se taire. C'est un gros troll, quoi.
[^] # Re: Mini précision, variable d'environnement
Posté par benoar . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 1.
Bah, l'implémentation d'upstrart est pourrie, et ? Tu relances au premier SIGSTOP uniquement, et c'est bon (tu vas me sortir le coup du mec qui SIGSTOP entre le lancement du programme et la fin de l'initialisation, je te sortirais qu'on ne demande pas une solution extrêmement parfaite ; c'est un truc pour aider ceux qui ne veulent pas dépendre de systemd).
Mouai, alors toi tu n'as pas du faire beaucoup d'empaquetage de logiciels. Quand tu fais réellement de l'intégration, ajouter une dépendance n'est pas du tout anodin. Après, je ne dis pas que c'est insurmontable, mais c'est ajouter des milliers de fois une charge qui pourrait être évitée (enfin, très réduite) si systemd l'implémentait.
[^] # Re: Bof
Posté par benoar . En réponse au journal Nourrir les vaches ! Openbsd a reçu des fonds.. Évalué à 3.
La « valeur » du m² qui augmente, c'est sa valeur marchande. La valeur d'usage du m², elle sera à peu près toujours la même (en fonction de son utilisation, quand même), car on ne va pas se mettre à faire des maisons 10 fois plus grandes ou réussir à trouver du blé avec un rendement 10 fois supérieur demain. Ton entreprise, déjà son nombre d'action peut augmenter comme il veut, et le « bien » qu'elle peut faire n'est pas limité réellement par une quantité physique.
Je comprends que notre économie partage certaines caractéristiques avec le Bitcoin, mais quand même, ça faisait longtemps qu'on n'était pas « reparti à zéro » sur un bien spéculatif, et que tout le monde trouve ça « normal ».
Moi, je voyais plutôt immoral son acquisition en tant que miner. Je n'aime pas non plus les spéculateurs, mais miner pour spéculer… c'est très immoral.
Oui, je suis d'accord que ça n'est pas forcément le meilleur angle d'attaque dans l'absolu, et j'essaye de ne pas me concentrer sur ça. Mais c'était juste pour rappeler certaines considérations morales qui sont encore plus valables avec le Bitcoin.
[^] # Re: Évolution
Posté par benoar . En réponse au journal Système de Dé-ciblage (google and co) pour augmenter l'anonymat. Évalué à 2.
Faux. Ça s'appelle le “Real-time bidding”, ces informations sont négociées à chaque impression, en fonction de la localisation, de ton historique de navigation, de ton profile, etc. C'est comme le High Frequency Trading, mais c'est toi la marchandise qui est échangée à haute vitesse.
Voir https://support.google.com/adxbuyer/answer/166635?ref_topic=27574&rd=1 par exemple, et généralement les infos sur le fonctionnement de la régie de Google : https://support.google.com/adxbuyer/#topic=21122
[^] # Re: Bof
Posté par benoar . En réponse au journal Nourrir les vaches ! Openbsd a reçu des fonds.. Évalué à 2.
Moi je vois quand même des choses différentes : le terrain, c'est un bien limité. L'entreprise, c'est quelque chose qui doit « créer de la valeur », à priori sans limite supérieure. Soit tu fais comme dans le Far West et chacun se sert jusqu'à ce qu'il n'y en ait plus, et tant pis pour ceux qui ne se sont pas servis, soit tu te dis au bout d'un moment qu'il faudrait quand même trouver des règles équitables, car sinon c'est trop vite le bordel et certains vont devenir « injustement » riches. Dans un autre commentaire, une moule parlait de « jalousie » : bien que pour certains c'est peut-être ça, le but au final c'est quand même, pour moi et sûrement d'autres, d'être équitable. Et donc, de ne pas participer à une chose si celle-ci n'est pas équitable.
Bitcoin n'est pas équitable (oui, comme plein d'autres « marchés » ou autres distributions de ressources) et donc je n'ai pas envie d'y participer. Je trouve ça dommage que d'autres le fassent, car ce faisant ils augmentent l'attrait global vers ce système inéquitable. Comme cette donation pour OpenBSD : le mec la fait en en parlant bien, histoire de crédibiliser cette monnaie. Donc, ceux qui y participent ne sont pas seulement « chanceux », ils entraînent également d'autres personnes dans ce cercle inéquitable en rendant ce système plus « respectable ». Après, dans l'absolu, oui, on ne va pas empêcher machin de faire ci ou ça, mais bon, les lois qu'on a obéissent à une certaine morale, généralement.
Oui, effectivement. Est-donc pour ça qu'il ne faut rien faire contre ? Commencer par ne pas promouvoir un tel système en n'y participant pas est déjà pas mal.
[^] # Re: Euh...
Posté par benoar . En réponse au journal Système de Dé-ciblage (google and co) pour augmenter l'anonymat. Évalué à -2.
Tu comprends qu'on puisse te trouver extrêmement lourd avec ce genre de commentaire ? Non ? T'as rien de mieux à foutre ?…
[^] # Re: Mini précision, variable d'environnement
Posté par benoar . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 9.
Quand on voit la réponse de Lennart https://bugzilla.redhat.com/show_bug.cgi?id=833105, on ne peut s'empêcher de voir la mauvaise foi de partout : il ignore l'utilisation de SIGSTOP seulement si un flag/variable d'environnement est mis, dit que ça peut être utilisé pour autre chose, mais là c'est dans le cas où le process l'utilise sur lui-même, il indique qu'il ne voit pas de différence entre appeler une fonction de la libc et introduire une dépendance à sa lib (il doit s'en foutre du boulot de mise à jour de tous les paquets, même les plus vieux/exotiques/etc…), … Alors que le rapport original demande juste une simple mesure pour être compatible optionnellement avec certains programmes !
Il est trop reulou. Techniquement, c'est à dire au niveau des capacités, je trouve que systemd bat de loin tous les autres. Ça serait la raison qui me fait le supporter. Mais entre son implémentation lourdingue, sa volonté de vouloir tout remplacer d'un coup (génial), l'intégration de tout dans systemd ce qui rend udev et d'autres utilitaires essentiels forcément dépendants de systemd sans toujours de bonne raisons, le « j'en n'ai rien à foutre des autres qui ne peuvent pas suivre », et l'ego démesuré de ce mec… c'est super chiant. Alors oui, je ne vois pas de solution aussi « bien » que la sienne, mais on sent tellement une sorte d'imposition de l'avis de RedHat sur un paquet de choses d'un coup, et que plein de monde va être largué parce que non compatible, que ça fait très peur.