D'une part, ça fait des mois que ça dure. D'autre part, Jonathan peut faire tout autant de bruit avec ou sans l'aval de l'UCC. La seule différence, c'est que l'UCC a dit "on demande à bosser avec quelqu'un d'autre". Croire que Kubuntu a une influence sur une potentiel entrée en bourse de Canonical, c'est se leurrer sur l'importance du libre pour le reste du monde.
Le fait d'avoir des gros clients, etc, ça, ça peut influencer. les discussions d'une personne sur le web, pas trop.
En fait, en regardant plus en détails, c'est le communauté des membres qui votent. Et les membres sont acceptés par le council en premier lieu. Donc tu veux te présenter au KC, faut avoir eu l'aval une fois du conseil ( sinon, tu es pas membre ), et se faire élire par les membres ( eux même nommé par le KC ).
Donc la seule différence avec l'UCC, c'est que c'est pas présenté de manière aussi explicite qu'il y a reproduction de l'existant.
Et je pense qu'en effet, on est loin de la démocratie tel qu'on l'imagine ou la majorité des gens ont le droit de vote juste par le fait d'être né à un endroit, voir d'y vivre.
Le Kubuntu Council (KC), quand à lui, représente la communauté
Kubuntu, et est élu par elle (sans filtre).
Alors faut préciser, le KC est la communauté des contributeurs. Si tu as pas le temps, pas l'envie ou pas les capacités de contribuer, tu oublies toute participation démocratique.
C'est un peu l'équivalent des grands électeurs en politique.
C'est bien joli d'avoir "une personne, une voix", mais "sans filtre" est trompeur faux. Il y a le filtre de pouvoir contribuer assez longtemps.
On en reviens au fait que la justice va se contenter de ce que la SG lui donne. Si les données ont aussi besoin d'expert dans le domaine, faut le trouver. Soit c'est quelqu'un de la SG, soit c'est un concurent. Dans les 2 cas, il y a un certain risque. On pourrait mitiger ça en ayant X experts et en supposant aucune collusion, mais ça deviens assez couteux, soit à la justice ( qui doit payer les dits experts ), soit pour les experts ( qui sont payer moins bien que la normal ).
Je vois pas de solution magique qui n'enfume pas un des participants ( et qui du coup, nuit à la bonne marche de la chose ). La solution serait sans doute dans l'existence d'experts payés soit par les assurances, soit employé pour ça par une administration ( un peu comme ce qui fait pour l'aviation ).
Mais bon, si c'est pas le cas pour le moment…
Et au passage, si les données sont dans le format d'un soft interne de la SG, le concept de format ouvert ou fermé, ou de soft libre ou pas ne s'applique pas aussi bien que pour le reste.
Non "nul n'est censé ignorer la loi", c'est pour justement éviter de plaider "je savais pas lire ou j'étais pas au courant donc je suis pas coupable". Rien de plus.
Alors, l’intérêt d'un nom de domaine est multiple.
D'abord, tu peux avoir le nom de domaine et changer de platforme d’hébergement. Le jour ou github sera devenu le nouveau sourceforge, les gens seront content de pouvoir basculer.
Ou si tu décides d'aller vers cloudflare ou un cdn devant ton site web, c'est pareil, un nom de domaine me semble requis.
Ensuite, si ton projet grandit, tu as parfois besoin d'avoir de l'infra en plus qui est pas exactement celle que propose github ( le cas qui me vient en tête serait d'avoir ton propre cdn, ton propre CI, etc ).
Je doute que ça soit le cas pour guake, mais c'est pas non plus impossible à envisager. Il y a suffisament de projets ou les CI existants sont pas suffisants ( parce que tu es pas root, parce que la plateforme est importante, parce que tu veux aller au dela des 2 versions d'ubuntu de travis, parce que tu as une communauté assez grande et github suffit pas pour la gestion des identités, etc ).
Parfois, tu trouves ça classe d'avoir ton alias mail. Ça simplifie quand même grandement la vie quand tu changes de provider mail, ou que des gens quittent le projet.
Enfin, je pense que si jamais tu as des histoires de trademarks, avoir le nom de domaine depuis X années peut aider quand même à convaincre que tu as utilisé le nom du projet depuis assez longtemps.
Tu peux faire un transfert de l'argent, puis annuler le transfert une fois que le nom de domaine est sous ton controle /o\
Ou tu peux lui faire appeler un numero surtaxé en france pour discuter avec toi, et une fois que tu as chopé les 400$ , tu lui verses, et il aura sa facture à la fin du mois .
D'un point de vue purement pragmatique, le fait de ne pas avoir d'ip stable et en multicast rends la solution moins attractive pour la configuration par défaut.
Du coup, on passe d'une ligne de config à "avoir une liste de serveur DNS dont on est pas sur de la survivance sur 5 ans". Ce qui deviens un patch plus intrusif à maintenir, vu qu'il faudrait soit coder en dur 3/4 serveurs de la liste ( ce qui est un risque ), soit avoir la liste des serveurs sur le disque, et la garder à jour ( donc accepter que le dns ne marche pas la première fois, surtout pour mettre les mises à jours ). Et rajouter aussi du code pour trouver le DNS le plus proche d'un point de vue réseau, alors que c'est le boulot du réseau de faire ça ( et la latence du DNS est importante quand même ).
Alors on va me dire que Google n'a pas vraiment un historique au niveau de garder les choses en marche longtemps, mais je pense qu'ils ont plus de moyen et plus d'appareil qui dépendent du fait que 8.8.8.8 réponde.
Mais bon, peut etre que c'est une vaste conspiration plutôt que le fait de pas vouloir maintenir un patch que personne n'a jamais écrit, sans doute parce qu'il est plus facile de râler sur un volontaire que de réfléchir à une solution.
Non, c'est la tendance qu'on retrouve partout. Soit tu fait des paquets et du code, soit tu es considéré comme un merde avec des talents périphériques.
Exemple:
- pendant trés longtemps, tu voulais avoir un droit de vote et un email @debian.org, il fallait devenir packageur. Les autres contributions ne comptait visiblement pas.
Autre exemple, tout le monde s'estime compétent en expérience utilisateur, même quand les gens sont pas capables de s'exprimer et d'employer le vocabulaire du domaine, et c'est un signe de non reconnaissance de l'expértise des gens qui bossent dedans ( et du coup, faut pas s'étonner de pas les voir venir se faire pourrir )
Ou le manque de considération qu'on donne aux documentations et/ou aux traductions, qu'on va voir comme tache pour débutant.
Ou tout ce qui est proche de l'application d'une forme d'empathie est vu comme une perte de temps. Discuter sur irc avec les utilisateurs, passer du temps sur les mailings listes de support, etc ( et c'est un truc qu'on retrouve aussi dans les startups : http://www.laurenbacon.com/women-tech-empathy-work/ )
Mais, oui, c'est bien que ça change, et qu'un peu de diversité dans la contribution arrive, et qu'elle arrive parce qu'il y a un début de diversité tout court sur des plans autre que la géographie et le type de bureau favori.
mais toutes ces informations sont enregistrées d’une façon
cohérente dans tous les fichiers de logs et sont parsables sans
surprise).
Sans surprise, autre que "j'ai changé la langue du systeme et le timestamp a changé". Et sans surprise autre que "j'ai des entrées multilignes dans les logs et ça peut foutre la zone dans mes scripts" ? Ou sans surprise autre que "c'est relou de faire des calculs sur les dates comme trouver tout depuis 1h30" quand tu regardes pour des infos à partir de 1h15 du mat ?
Je sais pas si j'ai vraiment la poisse ou si j'ai juste gardé mon ame d'enfant, mais ça, j'appelle ça des surprises. Des trucs auquel tu penses pas sur le coup, mais dés qu'il faut s'y mettre "surprise".
Les programmes qui se chargent eux-mêmes de leurs propres logs
(souvent avec leur propre format) au lieu de passer par le
démon de journalisation du système poseront toujours problème,
Comme tu le dit, l'interface de syslog, c'est d'ouvrir /dev/log, d'écrire dedans., c'est "tu files une ligne + la priorité" ( man 3 syslog ).
L'interface de journald, c'est soit tu utilises la même chose que syslog ( sd_journal_print ), soit tu utilises sd_journal_send ou tu passes des couples clés/valeurs.
Donc à partir de la, si mod_security veut du clé valeur, soit ils vont faire comme maintenant, cad écrire du structuré que personne ne va lire facilement ( en l'occurence, ça passe via les logs standards d'apache, c'est pas lui qui va écrire ), et qui va arriver avec le reste dans un fichier texte avec un bon mix.
Soit utiliser journald, ou la même chose va arriver, mais ou le filtrage du mix est builtin, pour peu que mod_security fasse ce qu'il faut.
Tu dis que personne ne se sert de l'envoi de messages structurés alors qu'on pouvait depuis longtemps. Mais c'est exactement ce que mod_security fait, et c'est la plaie, parce que justement, il fait ce que les autres ne font pas, cad envoyer du structuré et qu'il faut quelque chose pour s'en occuper.
Et c'est parce que c'est la plaie de faire ça avec la machinerie de syslog que personne le fait. Et ça n'a pas pris pour des questions de poule et d'oeuf.
Personne ou presque ne s'en sert parce qu'aucun format/lib/systéme n'a pris. Et donc aucune interface de recherche n'a été adopté par les gens en standard au delà de grep. Comme tout les trucs qui proposent ça sont lourd ( splunk/elk/graylog ), seul les gros groupes déploient ça, donc pas de standard, donc rien ne prends. Et Journald, qui fait ça de façon plus simple pour l'admin, a changé ce cycle de 2 façons.
Primo, en rajoutant l'information de structure sans demander au programme. Tu as l'unité, le pid, etc, etc. Et de façon uniforme sur tout les daemons juste en se mettant au bon endroit. Quelqu'un qui aurait voulu mettre l'info dispo aurait juste eu à coder le support dans rsyslog et à mettre une configuration par defaut. Mais à la place, l'approche des gens, c'était "on va mettre ça sur chaque daemon", ce qui visiblement n'a pas pris.
Les utilisateurs ont un souci, ils vont voir l'upstream. l'upstream va juste penser à influencer son soft, pas l'ecosystéme autour, et on arrive à la situation plus haut.
Secondo, une fois que l'information était la, il suffisait juste de rajouter une interface pour l'utiliser ( journalctl, en l'occurrence ). Et une fois que tu commences à utiliser l'info, tu continues.
Bien sur, ça aurait pu être fait avant et sans journald, qui n'a rien de magique à ce niveau ( aprés tout, Windows NT le fait depuis un bout de temps ). Mais comme maintenant, c'est en place, ça commence à être adopté.
Non, parfois deployer une machinerie complexe style ELK, Graylog, splunk n'est pas une meilleur option si ça te rajoute juste du taf sans rajouter des fonctions significativement requises.
L'admin sys, c'est pas gratuit, et je pense qu'il faut prendre sa remarque dans cet optique aussi.
la question est pas tant "texte" vs "binaire" que le degré de structuration que tu mets dans le format.
Un format XML va être du texte, va avoir une structure, et les métadonnées pour l’interpréter. Un format binaire qui est juste un dump mémoire ( comme le .doc l'était ) va pas avoir la structure.
Donc ça depend plus du format que juste "binaire" vs "texte". C'est un détail d'encodage en pratique.
Mais dans le cas des logs, les logs de syslog n'ont pas de structure et les logs de journald en ont.
Y a du pour et du contre, le fait de pas avoir de structure est plus rapide à développer et moins rigide vu que tu fais ce que tu veux. Exemple si je veux rajouter un truc à la fin des logs, j'ai pas à faire changer un schema ou quoi que ce soit.
Mais du coup, l’interopérabilité en souffre, dans le sens ou je peux pas m'appuyer sur le format. Et ça, c'est relou. Exemple, le format de mod_security est relou, vu qu'il log dans un premier fichier avec un format difficilement lisible par un humain, puis donne des détails dans un 2eme, un chouia plus difficilement scriptable car sur plusieurs lignes. Le fait d'inventer son format fait que je doit refaire la machinerie pour chercher la bas.
Donc la discussion devrait être "structure" vs "non structure".
Pas "texte" vs "pas texte". Car des formats texte de log avec une structure, y a gelf par exemple, qui peut être compressé et non compressé. Et même de manière plus amusante, il y a des convertisseurs ( https://github.com/systemd/journal2gelf ) depuis journald, parce que justement, il y a une structure.
J'ai du mal à voir en quoi une mise à jour peut être à la fois "significative" et en même temps "ne rien changer pour personne". Tu as juste changer le format de compression, ce qui est comme tu le dit un détail.
Sinon, il manque aussi le fait de devoir stocker le format de compression quelque part, sinon, ton format est indéfini ( déjà que les logs sont pas dans des formats définis de base ).
Et tu compares des choses en faisant preuve d'un manque de vision assez curieux. Tu part du principe que tu peux mettre à jour la chaine de traitement pour le cas ou ça t'arrange ( format texte ) mais pas pour le cas ou ça t'arrange pas, alors que ça peut se faire avec la même difficulté dans les 2 cas. Dans un cas, tu va avoir une routine de décompression, dans l'autre aussi. Dans un cas, tu va devoir spécifier le type de compression, dans l'autre aussi. Sauf que dans le cas ou ça t'arrange, c'est facile et rapide, et dans le cas ou ça t'arrange pas, c'est impossible. Mais sans justification aucune, ce qui est normale vu qu'il y a aucune raison logique à ça.
Le plus gros souci de tout ton argumentaire, c'est que tu confonds "dump de texte non structuré" avec "format texte".
Et si ton exemple d'évolution du texte non structuré, c'est "changer le format de compression", tu te fourres le doigt dans l'oeil sur la réalité des choses. Ce qui arrive bien plus souvent, c'est que le format de sortie change. Parce que tout d'un coup, tu as mis un nouveau module qui rajoute des choses ( exemple, tu passes tes serveurs webs derrière des proxys, donc tu veux logguer le X-forwarded-for en plus du proxy qui a fait le relais ). Ou tout d'un coup, tu as mis de l'ipv6. Et la, c'est le drame. Parce que tout d'un coup, ton script qui compte les champs avait pas prévu que tu tu aurais un champ de plus. Parce que tout d'un coup, ton champ texte qui est toujours la est tout d'un coup plus grand, avec un format différent. Parce que tout d'un coup, ton script qui fait que de l'ascii doit gérer l'unicode parce que quelqu'un utilise de l'IDN.
Prendre les données sans le reste de la chaine en croyant que "ça suffit", c'est se planter.
Bah, si tu veux la réponse, tu peux te poser la question à toi même.
Sinon, ça existe déjà, ça s'appelle SQL ( le standard SQL qui date d'avant awk, je tiens à rappeller ). Tu as tes données, tu fait des selects, des LIMIT, des clauses WHERE, etc comme tu ferait avec grep/awk/sed. Et des requêtes sur les requetes, pour les bases de données assez avancés. Et des stockages en tables temporaires aussi, si tu as envie.
Sinon, plus prosaïquement, le reste du monde n'a pas attendu que tu te poses des questions, et le monde scientifique a depuis longtemps des notebooks, comme zeppelin, ipython/jupyter. Sans vouloir trop m'avancer, je pense que l'inspiration vient de maple ou mathematic, et que l'idée, c'est d'avoir un cli amélioré via le browser.
Et pour tout ce qui est big data, ç'est le truc que propose tout les éditeurs de ce que je vois du marché.
Par exemple, Zeppelin te permet d'interroger ton cluster spark pour faire des requêtes sur les flux en streaming, requêtes qui sont peu ou prou semblables aux concepts de grep/awk/etc. Et q
Tu fait des fausses dichotomies. C'est surtout dépendant de comment tu spécifie ton format.
Si tu dit "le timestamp est une chaine de maximum 10 caracteres", alors le jour ou tu passes à 11, tu casses tout et c'est du texte.
Si tu as un format binaire avec un entête qui donne la longueur ou ce genre de choses ( ce qui est fait par exemple en ipv6 ), alors tu peux gérer la transition.
Et les délimiteurs sont pas sans poser des soucis, tel que "devoir les échapper". je fait quoi si j'ai besoin d'avoir un espace ou ':' dans ma chaine ?
Le gros avantage du texte, c'est la stabilité très longue durée
(Unix à plus de 40 ans). Un format binaire est incapable de
vivre aussi longtemps. Par exemple du C de 1990 est toujours
compilable à l'heure actuelle, même s'il peut être difficile
de l'exécuter (problème de librairie). Un binaire, c'est
quasiment impossible d'en tirer encore quoi que ce soit.
Tu aurais du commencer par ça, parce que la, j'aurais compris que tu as visiblement aucun recul et que tu mélanges tout. J'aurais pas pris la peine de répondre.
Primo, tu peux toujours lire les fichiers zip et afficher les bmp des années 80. Donc tu repasseras pour le fait d'être incapable de durer aussi longtemps. La principale raison de la longévité d'une information, c'est d'avoir un standard qui décrit quoi faire des données, pas d'être au format texte. Par exemple, va prendre des fichiers xml sans avoir la dtd ou l'info de ce que doit faire, tu va t'éclater à tirer des informations de ton format "perenne" en mode texte.
Secondo, si ton programme C des années 90 est compilable, y a des chances qu'il s’exécute aussi. Pas forcement qu'il s’exécute correctement si il fait de la merde toléré à l'époque qu'on bloque maintenant. Ça a beau être du texte, encore une fois, ce qui est important, c'est l'usage qui est fait de l'information, pas le format.
D'après stackoverflow, il suffit juste d'utiliser le module struct de python. Parait que c'est un langage sympa, faudrait regarder.
Mais je pense que la question est purement réthorique, parce que malgré la doc présente sur le web ( http://www.freedesktop.org/wiki/Software/systemd/journal-files/ ) depuis des années et le fait qu'il existe 2/3 bouts de code pour le faire ( https://github.com/Lagg/c3-code/blob/master/journal.c et https://github.com/Laird-Dave/journaldparser/blob/master/extractor.py ), le fait est que personne n'a pris la peine ( ie, l'aprés midi de travail ) de faire quoi que ce soit de propre pour windows ou pour mac. Ça montre surtout que l'intersection des gens motivés et/ou capables de coder pour ces platformes et des gens ayant le besoin est proche de pas grand chose. Et c'est pas faute pourtant d'avoir des tas de gens qui disent qu'il faut le faire, vu le nombre de commentaires disant qu'il y a un souci et tout va exploser.
Si franchement, un mec arrive à coder ça dans le cadre d'un tutorial youtube en écrivant les 250 lignes requises de code, c'est que ça doit pas être si terrible.
Donc si c'est pas la difficulté qui bloque, soit c'est parce que les gens sous Windows sont incapables, soit ils ont pas le besoin. Je ne pense pas que les Windowsiens sont incapables, et vu les pavés que hervé poste sur ce thread, je pense pas qu'on puisse garder l’hypothèse qu'il n'a pas le temps ( ça m'a pris 5 minutes de recherche sur le web pour trouver le code ).
Donc j'en conclus que le besoin est suffisament faible pour que quelqu'un se motive à faire un truc.
Et c'est pas vraiment compliqué de voir pourquoi. Si c'est sur un serveur, la majorité des OS utilisé ayant systemd a également les logs en texte à coté, cf config RHEL/Centos, et Debian, en partant du principe qu'il y a pas autre chose mise en place, genre splunk, ELK, etc.
Si c'est pas sur un serveur, c'est sur un poste client et/ou embarqué, ou une variante. Et si c'est sur un poste client, y a des chances de préférer un Linux par la.
Encore une fois, prendre le code python que j'ai pointé, en faire un module qu'on met sur pypi, faire des builds kivonbien, c'est moins d'une journée de travail pour quelqu'un d'assez compétent. J'ai écrit un gem ruby en partant de 0 en moins de 4h depuis un café en république tchèque y a grosso modo 1 an, donc j'imagine que pypi doit pas être fondamentalement plus complexe.
Donc si le but était d'être constructif plutôt que de déposer une énième logorrhée sur Linuxfr, quelqu'un s'y attellerait. Personne ne s'y attelle, donc je conclue que le but est juste de râler.
Moi, je pourrais en effet faire ce module, mais je vois pas pourquoi je devrais consacrer du temps gratuit à une plateforme que j'utilise pas, que j'ai pas envie d'utiliser. Mais si quelqu'un me file des thunes, je peux changer d'avis. J'ai l'intuition que personne ne va rien donner, donc ça doit pas être si critique que ça.
s/gaspillé/dépensé dans des boites francais ou certains ici bossent/
Faut aussi se dire que des gens chez Thales et EADS, y en a des tonnes. Que si les informaticiens sont pas au chomage, c'est grâce aussi à ça. Qu'on a Amesys, des cabinets de conseils ( HSC, etc ), et tout un tas d'acteurs qu'on retrouve pas forcément ailleurs.
Et que si on a des tonnes de confs de secu ( stiic, nuit du hack, hackito ergosum et les autres dont j'ai oublié le nom ) en france, c'est aussi ça parce que les gens qui s'intéresse à ça trouve du boulot, et donc font des affaires pour gagner leur vie.
Donc l'influence de lobbying de toute cette industrie ( dans laquelle j'ai bossé ) est un point non négligeable de tout ça. Un point qu'on voit pas souvent mis en avant, et qui est pourtant existant.
Et je parle pas non plus de experts en machine learning francais comme tinyclues ou criteo et tout ça, qui font que dans l'esprit des gens ordinaires, on peut faire des miracles avec les algos, et qu'à force de dire "on est suivi par google et facebook", personne ne se dit que ça cimente l'idée que c'est faisable et facile. Et c'est pas les vendeurs de solutions qui vont dire le contraire.
Spoiler: 1984 est une œuvre de fiction, si Georges Orwell avait voulu faire danser la carioca à Wilson, ça aurait la même valeur pour déduire de ce qui peut et va arriver dans le monde réel.
Je pense qu'on devrait commencer à utiliser des cas moins imaginaires, comme parler de ce qui est arrivé au régime soviétique, à l'Allemagne de l'ouest ( "la vie des autres" ), à celui de Saddam Hussein ( et la montée de l'etat islamique sur les ruines de sa bureaucratie militaire ) ou les autres dictatures. À la rigueur, la, on pourrais faire une comparaison qui soit pas littéralement basé sur une histoire inventé par un déçu du système soviétique. La biographie montre quand même que pour quelqu'un d'engagé, il n'avait pas l'air d'avoir non plus un recul énorme, cf la controverse rappelé sur Wikipedia francais. Il avait visiblement pas trop de souci avec le concept de propagande de l'état pour peu que ça soit pour une voie qu'il crois, et pas le recul vis à vis du respect de la vie privé qu'on pourrait s'attendre de l'auteur de 1984, chose qui pour l'époque se concoit, mais qui nuance quand même vachement la différence entre ce qu'il pensait, et ce qu'on va lire dans le roman.
Techniquement, une décriminalisation du canabis serait exactement ce genre de loi. Divers lois décriminalisant la fornication en dehors du mariage le serait aussi. Ou le divorce.
<sarcasme>
Quoi, des exemples réalistes de choses qui arrivent au lieu de ressortir la NSA comme épouvantail passe partout, mais ou va le monde ?</sarcasme>
[^] # Re: De l'eau dans le gaz ?
Posté par Misc (site web personnel) . En réponse au journal L'Ubuntu Community Council dit au leader de Kubuntu d'arrêter. Évalué à 7.
C'est un peu ridicule.
D'une part, ça fait des mois que ça dure. D'autre part, Jonathan peut faire tout autant de bruit avec ou sans l'aval de l'UCC. La seule différence, c'est que l'UCC a dit "on demande à bosser avec quelqu'un d'autre". Croire que Kubuntu a une influence sur une potentiel entrée en bourse de Canonical, c'est se leurrer sur l'importance du libre pour le reste du monde.
Le fait d'avoir des gros clients, etc, ça, ça peut influencer. les discussions d'une personne sur le web, pas trop.
[^] # Re: Grmblbl
Posté par Misc (site web personnel) . En réponse au journal L'Ubuntu Community Council dit au leader de Kubuntu d'arrêter. Évalué à 4.
En fait, en regardant plus en détails, c'est le communauté des membres qui votent. Et les membres sont acceptés par le council en premier lieu. Donc tu veux te présenter au KC, faut avoir eu l'aval une fois du conseil ( sinon, tu es pas membre ), et se faire élire par les membres ( eux même nommé par le KC ).
Donc la seule différence avec l'UCC, c'est que c'est pas présenté de manière aussi explicite qu'il y a reproduction de l'existant.
Et je pense qu'en effet, on est loin de la démocratie tel qu'on l'imagine ou la majorité des gens ont le droit de vote juste par le fait d'être né à un endroit, voir d'y vivre.
# Grmblbl
Posté par Misc (site web personnel) . En réponse au journal L'Ubuntu Community Council dit au leader de Kubuntu d'arrêter. Évalué à 5.
Alors faut préciser, le KC est la communauté des contributeurs. Si tu as pas le temps, pas l'envie ou pas les capacités de contribuer, tu oublies toute participation démocratique.
C'est un peu l'équivalent des grands électeurs en politique.
C'est bien joli d'avoir "une personne, une voix", mais "sans filtre" est trompeur faux. Il y a le filtre de pouvoir contribuer assez longtemps.
[^] # Re: Et mes actions ?
Posté par Misc (site web personnel) . En réponse au journal Mandriva c'est fini. Évalué à 4.
je propose qu'on se fasse rembourser les invitations.
Et qu'on aille danser la carioca.
[^] # Re: De ce que je sache
Posté par Misc (site web personnel) . En réponse au journal de l'utilité des formats ouverts. Évalué à 5.
On en reviens au fait que la justice va se contenter de ce que la SG lui donne. Si les données ont aussi besoin d'expert dans le domaine, faut le trouver. Soit c'est quelqu'un de la SG, soit c'est un concurent. Dans les 2 cas, il y a un certain risque. On pourrait mitiger ça en ayant X experts et en supposant aucune collusion, mais ça deviens assez couteux, soit à la justice ( qui doit payer les dits experts ), soit pour les experts ( qui sont payer moins bien que la normal ).
Je vois pas de solution magique qui n'enfume pas un des participants ( et qui du coup, nuit à la bonne marche de la chose ). La solution serait sans doute dans l'existence d'experts payés soit par les assurances, soit employé pour ça par une administration ( un peu comme ce qui fait pour l'aviation ).
Mais bon, si c'est pas le cas pour le moment…
Et au passage, si les données sont dans le format d'un soft interne de la SG, le concept de format ouvert ou fermé, ou de soft libre ou pas ne s'applique pas aussi bien que pour le reste.
[^] # Re: Et mes actions ?
Posté par Misc (site web personnel) . En réponse au journal Mandriva c'est fini. Évalué à 2.
Il dit qu'il voit pas le rapport.
[^] # Re: Et vice et versa
Posté par Misc (site web personnel) . En réponse au journal L'affaire Bluetouff. Évalué à 8.
Non "nul n'est censé ignorer la loi", c'est pour justement éviter de plaider "je savais pas lire ou j'étais pas au courant donc je suis pas coupable". Rien de plus.
[^] # Re: Intérêt d'un nom de domaine ?
Posté par Misc (site web personnel) . En réponse au journal Histoire d'un vol de domaine. Évalué à 10.
Alors, l’intérêt d'un nom de domaine est multiple.
D'abord, tu peux avoir le nom de domaine et changer de platforme d’hébergement. Le jour ou github sera devenu le nouveau sourceforge, les gens seront content de pouvoir basculer.
Ou si tu décides d'aller vers cloudflare ou un cdn devant ton site web, c'est pareil, un nom de domaine me semble requis.
Ensuite, si ton projet grandit, tu as parfois besoin d'avoir de l'infra en plus qui est pas exactement celle que propose github ( le cas qui me vient en tête serait d'avoir ton propre cdn, ton propre CI, etc ).
Je doute que ça soit le cas pour guake, mais c'est pas non plus impossible à envisager. Il y a suffisament de projets ou les CI existants sont pas suffisants ( parce que tu es pas root, parce que la plateforme est importante, parce que tu veux aller au dela des 2 versions d'ubuntu de travis, parce que tu as une communauté assez grande et github suffit pas pour la gestion des identités, etc ).
Parfois, tu trouves ça classe d'avoir ton alias mail. Ça simplifie quand même grandement la vie quand tu changes de provider mail, ou que des gens quittent le projet.
Enfin, je pense que si jamais tu as des histoires de trademarks, avoir le nom de domaine depuis X années peut aider quand même à convaincre que tu as utilisé le nom du projet depuis assez longtemps.
[^] # Re: C'est l'jeu ma pov' Lucette
Posté par Misc (site web personnel) . En réponse au journal Histoire d'un vol de domaine. Évalué à 10.
Tu peux faire un transfert de l'argent, puis annuler le transfert une fois que le nom de domaine est sous ton controle /o\
Ou tu peux lui faire appeler un numero surtaxé en france pour discuter avec toi, et une fois que tu as chopé les 400$ , tu lui verses, et il aura sa facture à la fin du mois .
[^] # Re: Quand systemd téléphone à Google
Posté par Misc (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 3.
D'un point de vue purement pragmatique, le fait de ne pas avoir d'ip stable et en multicast rends la solution moins attractive pour la configuration par défaut.
Du coup, on passe d'une ligne de config à "avoir une liste de serveur DNS dont on est pas sur de la survivance sur 5 ans". Ce qui deviens un patch plus intrusif à maintenir, vu qu'il faudrait soit coder en dur 3/4 serveurs de la liste ( ce qui est un risque ), soit avoir la liste des serveurs sur le disque, et la garder à jour ( donc accepter que le dns ne marche pas la première fois, surtout pour mettre les mises à jours ). Et rajouter aussi du code pour trouver le DNS le plus proche d'un point de vue réseau, alors que c'est le boulot du réseau de faire ça ( et la latence du DNS est importante quand même ).
Alors on va me dire que Google n'a pas vraiment un historique au niveau de garder les choses en marche longtemps, mais je pense qu'ils ont plus de moyen et plus d'appareil qui dépendent du fait que 8.8.8.8 réponde.
Mais bon, peut etre que c'est une vaste conspiration plutôt que le fait de pas vouloir maintenir un patch que personne n'a jamais écrit, sans doute parce qu'il est plus facile de râler sur un volontaire que de réfléchir à une solution.
[^] # Re: Thème graphique
Posté par Misc (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 4.
Non, c'est la tendance qu'on retrouve partout. Soit tu fait des paquets et du code, soit tu es considéré comme un merde avec des talents périphériques.
Exemple:
- pendant trés longtemps, tu voulais avoir un droit de vote et un email @debian.org, il fallait devenir packageur. Les autres contributions ne comptait visiblement pas.
Autre exemple, tout le monde s'estime compétent en expérience utilisateur, même quand les gens sont pas capables de s'exprimer et d'employer le vocabulaire du domaine, et c'est un signe de non reconnaissance de l'expértise des gens qui bossent dedans ( et du coup, faut pas s'étonner de pas les voir venir se faire pourrir )
Ou le manque de considération qu'on donne aux documentations et/ou aux traductions, qu'on va voir comme tache pour débutant.
Ou tout ce qui est proche de l'application d'une forme d'empathie est vu comme une perte de temps. Discuter sur irc avec les utilisateurs, passer du temps sur les mailings listes de support, etc ( et c'est un truc qu'on retrouve aussi dans les startups : http://www.laurenbacon.com/women-tech-empathy-work/ )
Mais, oui, c'est bien que ça change, et qu'un peu de diversité dans la contribution arrive, et qu'elle arrive parce qu'il y a un début de diversité tout court sur des plans autre que la géographie et le type de bureau favori.
[^] # Re: Suppression de DSPAM
Posté par Misc (site web personnel) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 3.
J'utilise pas jessie, mais j'utilise spamassasin aussi. Et j'ai vu https://rspamd.com/ , peut être à tester ?
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 8.
Sans surprise, autre que "j'ai changé la langue du systeme et le timestamp a changé". Et sans surprise autre que "j'ai des entrées multilignes dans les logs et ça peut foutre la zone dans mes scripts" ? Ou sans surprise autre que "c'est relou de faire des calculs sur les dates comme trouver tout depuis 1h30" quand tu regardes pour des infos à partir de 1h15 du mat ?
Je sais pas si j'ai vraiment la poisse ou si j'ai juste gardé mon ame d'enfant, mais ça, j'appelle ça des surprises. Des trucs auquel tu penses pas sur le coup, mais dés qu'il faut s'y mettre "surprise".
Comme tu le dit, l'interface de syslog, c'est d'ouvrir /dev/log, d'écrire dedans., c'est "tu files une ligne + la priorité" ( man 3 syslog ).
L'interface de journald, c'est soit tu utilises la même chose que syslog ( sd_journal_print ), soit tu utilises sd_journal_send ou tu passes des couples clés/valeurs.
Donc à partir de la, si mod_security veut du clé valeur, soit ils vont faire comme maintenant, cad écrire du structuré que personne ne va lire facilement ( en l'occurence, ça passe via les logs standards d'apache, c'est pas lui qui va écrire ), et qui va arriver avec le reste dans un fichier texte avec un bon mix.
Soit utiliser journald, ou la même chose va arriver, mais ou le filtrage du mix est builtin, pour peu que mod_security fasse ce qu'il faut.
Tu dis que personne ne se sert de l'envoi de messages structurés alors qu'on pouvait depuis longtemps. Mais c'est exactement ce que mod_security fait, et c'est la plaie, parce que justement, il fait ce que les autres ne font pas, cad envoyer du structuré et qu'il faut quelque chose pour s'en occuper.
Et c'est parce que c'est la plaie de faire ça avec la machinerie de syslog que personne le fait. Et ça n'a pas pris pour des questions de poule et d'oeuf.
Personne ou presque ne s'en sert parce qu'aucun format/lib/systéme n'a pris. Et donc aucune interface de recherche n'a été adopté par les gens en standard au delà de grep. Comme tout les trucs qui proposent ça sont lourd ( splunk/elk/graylog ), seul les gros groupes déploient ça, donc pas de standard, donc rien ne prends. Et Journald, qui fait ça de façon plus simple pour l'admin, a changé ce cycle de 2 façons.
Primo, en rajoutant l'information de structure sans demander au programme. Tu as l'unité, le pid, etc, etc. Et de façon uniforme sur tout les daemons juste en se mettant au bon endroit. Quelqu'un qui aurait voulu mettre l'info dispo aurait juste eu à coder le support dans rsyslog et à mettre une configuration par defaut. Mais à la place, l'approche des gens, c'était "on va mettre ça sur chaque daemon", ce qui visiblement n'a pas pris.
Les utilisateurs ont un souci, ils vont voir l'upstream. l'upstream va juste penser à influencer son soft, pas l'ecosystéme autour, et on arrive à la situation plus haut.
Secondo, une fois que l'information était la, il suffisait juste de rajouter une interface pour l'utiliser ( journalctl, en l'occurrence ). Et une fois que tu commences à utiliser l'info, tu continues.
Bien sur, ça aurait pu être fait avant et sans journald, qui n'a rien de magique à ce niveau ( aprés tout, Windows NT le fait depuis un bout de temps ). Mais comme maintenant, c'est en place, ça commence à être adopté.
Exemple, apache propose ça :
https://httpd.apache.org/docs/trunk/mod/mod_journald.html
Pareil pour cupsd ( https://fedoraproject.org/wiki/Changes/CupsJournalLogging )
Y a pas besoin que les gens s'y mettent, suffit juste d'avoir une configuration par défaut dans une distribution, et que ça soit intégré.
[^] # Re: Je sais qu’on est vendredi mais…
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 3.
Non, parfois deployer une machinerie complexe style ELK, Graylog, splunk n'est pas une meilleur option si ça te rajoute juste du taf sans rajouter des fonctions significativement requises.
L'admin sys, c'est pas gratuit, et je pense qu'il faut prendre sa remarque dans cet optique aussi.
[^] # Re: Je sais qu’on est vendredi mais…
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 1.
Parce que sqlite est monoprocessus, dans mon souvenir ( à l'époque du lancement de trac, ce qui remonte ).
Si tu écrit, tu lis pas. Mais on m'a dit que ça a finalement changé, donc peut être que je me trompe.
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 6.
la question est pas tant "texte" vs "binaire" que le degré de structuration que tu mets dans le format.
Un format XML va être du texte, va avoir une structure, et les métadonnées pour l’interpréter. Un format binaire qui est juste un dump mémoire ( comme le .doc l'était ) va pas avoir la structure.
Donc ça depend plus du format que juste "binaire" vs "texte". C'est un détail d'encodage en pratique.
Mais dans le cas des logs, les logs de syslog n'ont pas de structure et les logs de journald en ont.
Y a du pour et du contre, le fait de pas avoir de structure est plus rapide à développer et moins rigide vu que tu fais ce que tu veux. Exemple si je veux rajouter un truc à la fin des logs, j'ai pas à faire changer un schema ou quoi que ce soit.
Mais du coup, l’interopérabilité en souffre, dans le sens ou je peux pas m'appuyer sur le format. Et ça, c'est relou. Exemple, le format de mod_security est relou, vu qu'il log dans un premier fichier avec un format difficilement lisible par un humain, puis donne des détails dans un 2eme, un chouia plus difficilement scriptable car sur plusieurs lignes. Le fait d'inventer son format fait que je doit refaire la machinerie pour chercher la bas.
Donc la discussion devrait être "structure" vs "non structure".
Pas "texte" vs "pas texte". Car des formats texte de log avec une structure, y a gelf par exemple, qui peut être compressé et non compressé. Et même de manière plus amusante, il y a des convertisseurs ( https://github.com/systemd/journal2gelf ) depuis journald, parce que justement, il y a une structure.
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 4.
J'ai du mal à voir en quoi une mise à jour peut être à la fois "significative" et en même temps "ne rien changer pour personne". Tu as juste changer le format de compression, ce qui est comme tu le dit un détail.
Sinon, il manque aussi le fait de devoir stocker le format de compression quelque part, sinon, ton format est indéfini ( déjà que les logs sont pas dans des formats définis de base ).
Et tu compares des choses en faisant preuve d'un manque de vision assez curieux. Tu part du principe que tu peux mettre à jour la chaine de traitement pour le cas ou ça t'arrange ( format texte ) mais pas pour le cas ou ça t'arrange pas, alors que ça peut se faire avec la même difficulté dans les 2 cas. Dans un cas, tu va avoir une routine de décompression, dans l'autre aussi. Dans un cas, tu va devoir spécifier le type de compression, dans l'autre aussi. Sauf que dans le cas ou ça t'arrange, c'est facile et rapide, et dans le cas ou ça t'arrange pas, c'est impossible. Mais sans justification aucune, ce qui est normale vu qu'il y a aucune raison logique à ça.
Le plus gros souci de tout ton argumentaire, c'est que tu confonds "dump de texte non structuré" avec "format texte".
Et si ton exemple d'évolution du texte non structuré, c'est "changer le format de compression", tu te fourres le doigt dans l'oeil sur la réalité des choses. Ce qui arrive bien plus souvent, c'est que le format de sortie change. Parce que tout d'un coup, tu as mis un nouveau module qui rajoute des choses ( exemple, tu passes tes serveurs webs derrière des proxys, donc tu veux logguer le X-forwarded-for en plus du proxy qui a fait le relais ). Ou tout d'un coup, tu as mis de l'ipv6. Et la, c'est le drame. Parce que tout d'un coup, ton script qui compte les champs avait pas prévu que tu tu aurais un champ de plus. Parce que tout d'un coup, ton champ texte qui est toujours la est tout d'un coup plus grand, avec un format différent. Parce que tout d'un coup, ton script qui fait que de l'ascii doit gérer l'unicode parce que quelqu'un utilise de l'IDN.
Prendre les données sans le reste de la chaine en croyant que "ça suffit", c'est se planter.
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 1.
Bah, si tu veux la réponse, tu peux te poser la question à toi même.
Sinon, ça existe déjà, ça s'appelle SQL ( le standard SQL qui date d'avant awk, je tiens à rappeller ). Tu as tes données, tu fait des selects, des LIMIT, des clauses WHERE, etc comme tu ferait avec grep/awk/sed. Et des requêtes sur les requetes, pour les bases de données assez avancés. Et des stockages en tables temporaires aussi, si tu as envie.
Sinon, plus prosaïquement, le reste du monde n'a pas attendu que tu te poses des questions, et le monde scientifique a depuis longtemps des notebooks, comme zeppelin, ipython/jupyter. Sans vouloir trop m'avancer, je pense que l'inspiration vient de maple ou mathematic, et que l'idée, c'est d'avoir un cli amélioré via le browser.
Et pour tout ce qui est big data, ç'est le truc que propose tout les éditeurs de ce que je vois du marché.
Par exemple, Zeppelin te permet d'interroger ton cluster spark pour faire des requêtes sur les flux en streaming, requêtes qui sont peu ou prou semblables aux concepts de grep/awk/etc. Et q
Par exemple pour spark, voir word count, ou on chaine les traitements :
https://spark.apache.org/examples.html
Pareil pour jupyter/ipython et les autres.
Maintenant, libre à toi de rajouter des choses, ipython/jupyter a la possibilité aussi de traiter du bash :
http://jeroenjanssens.com/2015/02/19/ibash-notebook.html
[^] # Re: Pour toi?
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 8.
Tu fait des fausses dichotomies. C'est surtout dépendant de comment tu spécifie ton format.
Si tu dit "le timestamp est une chaine de maximum 10 caracteres", alors le jour ou tu passes à 11, tu casses tout et c'est du texte.
Si tu as un format binaire avec un entête qui donne la longueur ou ce genre de choses ( ce qui est fait par exemple en ipv6 ), alors tu peux gérer la transition.
Et les délimiteurs sont pas sans poser des soucis, tel que "devoir les échapper". je fait quoi si j'ai besoin d'avoir un espace ou ':' dans ma chaine ?
Tu aurais du commencer par ça, parce que la, j'aurais compris que tu as visiblement aucun recul et que tu mélanges tout. J'aurais pas pris la peine de répondre.
Primo, tu peux toujours lire les fichiers zip et afficher les bmp des années 80. Donc tu repasseras pour le fait d'être incapable de durer aussi longtemps. La principale raison de la longévité d'une information, c'est d'avoir un standard qui décrit quoi faire des données, pas d'être au format texte. Par exemple, va prendre des fichiers xml sans avoir la dtd ou l'info de ce que doit faire, tu va t'éclater à tirer des informations de ton format "perenne" en mode texte.
Secondo, si ton programme C des années 90 est compilable, y a des chances qu'il s’exécute aussi. Pas forcement qu'il s’exécute correctement si il fait de la merde toléré à l'époque qu'on bloque maintenant. Ça a beau être du texte, encore une fois, ce qui est important, c'est l'usage qui est fait de l'information, pas le format.
Donc l'argumentaire est un chouia myopique.
[^] # Re: Définition
Posté par Misc (site web personnel) . En réponse au journal Vivent les journaux binaires !. Évalué à 10.
D'après stackoverflow, il suffit juste d'utiliser le module struct de python. Parait que c'est un langage sympa, faudrait regarder.
Mais je pense que la question est purement réthorique, parce que malgré la doc présente sur le web ( http://www.freedesktop.org/wiki/Software/systemd/journal-files/ ) depuis des années et le fait qu'il existe 2/3 bouts de code pour le faire ( https://github.com/Lagg/c3-code/blob/master/journal.c et https://github.com/Laird-Dave/journaldparser/blob/master/extractor.py ), le fait est que personne n'a pris la peine ( ie, l'aprés midi de travail ) de faire quoi que ce soit de propre pour windows ou pour mac. Ça montre surtout que l'intersection des gens motivés et/ou capables de coder pour ces platformes et des gens ayant le besoin est proche de pas grand chose. Et c'est pas faute pourtant d'avoir des tas de gens qui disent qu'il faut le faire, vu le nombre de commentaires disant qu'il y a un souci et tout va exploser.
Si franchement, un mec arrive à coder ça dans le cadre d'un tutorial youtube en écrivant les 250 lignes requises de code, c'est que ça doit pas être si terrible.
Donc si c'est pas la difficulté qui bloque, soit c'est parce que les gens sous Windows sont incapables, soit ils ont pas le besoin. Je ne pense pas que les Windowsiens sont incapables, et vu les pavés que hervé poste sur ce thread, je pense pas qu'on puisse garder l’hypothèse qu'il n'a pas le temps ( ça m'a pris 5 minutes de recherche sur le web pour trouver le code ).
Donc j'en conclus que le besoin est suffisament faible pour que quelqu'un se motive à faire un truc.
Et c'est pas vraiment compliqué de voir pourquoi. Si c'est sur un serveur, la majorité des OS utilisé ayant systemd a également les logs en texte à coté, cf config RHEL/Centos, et Debian, en partant du principe qu'il y a pas autre chose mise en place, genre splunk, ELK, etc.
Si c'est pas sur un serveur, c'est sur un poste client et/ou embarqué, ou une variante. Et si c'est sur un poste client, y a des chances de préférer un Linux par la.
Encore une fois, prendre le code python que j'ai pointé, en faire un module qu'on met sur pypi, faire des builds kivonbien, c'est moins d'une journée de travail pour quelqu'un d'assez compétent. J'ai écrit un gem ruby en partant de 0 en moins de 4h depuis un café en république tchèque y a grosso modo 1 an, donc j'imagine que pypi doit pas être fondamentalement plus complexe.
Donc si le but était d'être constructif plutôt que de déposer une énième logorrhée sur Linuxfr, quelqu'un s'y attellerait. Personne ne s'y attelle, donc je conclue que le but est juste de râler.
Moi, je pourrais en effet faire ce module, mais je vois pas pourquoi je devrais consacrer du temps gratuit à une plateforme que j'utilise pas, que j'ai pas envie d'utiliser. Mais si quelqu'un me file des thunes, je peux changer d'avis. J'ai l'intuition que personne ne va rien donner, donc ça doit pas être si critique que ça.
[^] # Re: des surprises dans les votes pour et contre
Posté par Misc (site web personnel) . En réponse au journal Adoption du projet de loi relatif au renseignement en première lecture. Évalué à 2.
s/gaspillé/dépensé dans des boites francais ou certains ici bossent/
Faut aussi se dire que des gens chez Thales et EADS, y en a des tonnes. Que si les informaticiens sont pas au chomage, c'est grâce aussi à ça. Qu'on a Amesys, des cabinets de conseils ( HSC, etc ), et tout un tas d'acteurs qu'on retrouve pas forcément ailleurs.
Et que si on a des tonnes de confs de secu ( stiic, nuit du hack, hackito ergosum et les autres dont j'ai oublié le nom ) en france, c'est aussi ça parce que les gens qui s'intéresse à ça trouve du boulot, et donc font des affaires pour gagner leur vie.
Donc l'influence de lobbying de toute cette industrie ( dans laquelle j'ai bossé ) est un point non négligeable de tout ça. Un point qu'on voit pas souvent mis en avant, et qui est pourtant existant.
Et je parle pas non plus de experts en machine learning francais comme tinyclues ou criteo et tout ça, qui font que dans l'esprit des gens ordinaires, on peut faire des miracles avec les algos, et qu'à force de dire "on est suivi par google et facebook", personne ne se dit que ça cimente l'idée que c'est faisable et facile. Et c'est pas les vendeurs de solutions qui vont dire le contraire.
Exemple :
https://www.youtube.com/watch?v=6uGQeA3x0bs
En dehors du coté anti jeunes qui m'étonne pas, le clip est quand même anxiogène au possible…
[^] # Re: mettre le net à sa place ?
Posté par Misc (site web personnel) . En réponse au journal Adoption du projet de loi relatif au renseignement en première lecture. Évalué à 4.
Spoiler: 1984 est une œuvre de fiction, si Georges Orwell avait voulu faire danser la carioca à Wilson, ça aurait la même valeur pour déduire de ce qui peut et va arriver dans le monde réel.
Je pense qu'on devrait commencer à utiliser des cas moins imaginaires, comme parler de ce qui est arrivé au régime soviétique, à l'Allemagne de l'ouest ( "la vie des autres" ), à celui de Saddam Hussein ( et la montée de l'etat islamique sur les ruines de sa bureaucratie militaire ) ou les autres dictatures. À la rigueur, la, on pourrais faire une comparaison qui soit pas littéralement basé sur une histoire inventé par un déçu du système soviétique. La biographie montre quand même que pour quelqu'un d'engagé, il n'avait pas l'air d'avoir non plus un recul énorme, cf la controverse rappelé sur Wikipedia francais. Il avait visiblement pas trop de souci avec le concept de propagande de l'état pour peu que ça soit pour une voie qu'il crois, et pas le recul vis à vis du respect de la vie privé qu'on pourrait s'attendre de l'auteur de 1984, chose qui pour l'époque se concoit, mais qui nuance quand même vachement la différence entre ce qu'il pensait, et ce qu'on va lire dans le roman.
[^] # Re: Mouai
Posté par Misc (site web personnel) . En réponse au journal Adoption du projet de loi relatif au renseignement en première lecture. Évalué à 3.
Techniquement, une décriminalisation du canabis serait exactement ce genre de loi. Divers lois décriminalisant la fornication en dehors du mariage le serait aussi. Ou le divorce.
[^] # Re: faut deja un acces aux données
Posté par Misc (site web personnel) . En réponse au journal Encfs déclaré relativement peu sûr. Évalué à 5.
<sarcasme>
Quoi, des exemples réalistes de choses qui arrivent au lieu de ressortir la NSA comme épouvantail passe partout, mais ou va le monde ?</sarcasme>
# Comment on propose ?
Posté par Misc (site web personnel) . En réponse à la dépêche Ubuntu Party Paris mai 2015 - appel à conférence. Évalué à 2.
J'ai pas trop trouvé comment proposer un ou deux talks sur le site web ( mais je suis aussi un peu fatigué ). Quelqu'un voit un lien évident ?