from:"Laurent Franceschetti"

"C’est mal de penser à mal, mais des fois on tombe juste". En général c’est 
comme ça qu’on devrait mener une enquête sérieuse : en droit ça s’apppelle des 
« soupçons fondés » (voir par exemple explications de la FINMA 

 dans le cadre bancaire).

Il y a pas mal de choses un peu curieuses autour de cette appli, à commencer 
par le contexte politique du développement au sein de l’EPFL. Le fait que le 
rapport du professeur Vaudenay du Laboratoire de sécurité et de cryptographie 
(LASEC) avait été gardé sous embargo pendant qu’on discutait la loi au 
parlement en juin, pendant qu’on envoyait un autre parler aux médias. Et 
ensuite (au moment où la loi avait été votée) le MELANI a berne avait fourni un 
« extrait » avec des contre-arguments en face, qui était en réalité un démenti; 
ce qui revenait à remettre les compétences du professeur de cybersécurité en 
question. Personnellement, j’avais trouvé ça mesquin.

Voici la version des faits du prof. Vaudenay, avec les détails 
.

Citation:

> SwissCovid was developed and deployed in a rush, with the pressure of the 
> pandemic. It is remarkable that SwissCovid was fully deployed so fast. We 
> find the adoption rate to be currently quite high (although it does not match 
> the dreams of the developers). We however believe that the scientific debate 
> was sabotaged by scientific lobbying and that we were mostly faced to a fait 
> accompli. A vast conflict-of-interest factory around SwissCovid was built by 
> having the same people being the developers, the evaluators, the advisors, 
> the communicators, the operators, and the rulers. Alternate solutions were 
> trashed. Criticisms were downplayed. Potential threats were ignored. Positive 
> evaluation reports were posted and negative ones were not. Pseudo-scientific 
> proofs were forged to support pre-agreed conclusions. Press was manipulated 
> to spread conclusions. Essentially, SwissCovid begs Swiss residents to keep 
> faith in that SwissCovid is or will be useful without any objective evidence. 
> The security and privacy claims are smokescreens. We think that people were 
> deceived.  


Et effectivement, le discours de SwissCovid autour de « logiciel libre » 
sonnait artificiel, tout en minimisant le fait qu’ils avaient abandonné leur 
propre développement pour construire leur appli autour d’API fermées d’Apple et 
Google. 

Sans compter l’attitude face aux objections « vous êtes mal informé, Monsieur, 
écoutez les sachants ». Je veux bien qu’on nous dise que nous n’y connaissons 
pas assez en médecine, parce que c’est vrai. Mais si à force de s'entendre 
répéter qu’on ne connait pas assez l’informatique pour poser des questions (et 
tout le monde y passe, y-compris un professeur de sécurité et de cryptographie 
du poly), on finit par avoir l’impression qu’un certain nombre de gens sont en 
train de se moquer du reste du monde.

Bref, les deux choses qui éveillent l'attention dans cette affaire c’est a) 
l’écran de fumée, b) le manque de transparence. Il y a de quoi justifier de 
continuer à poser beaucoup de questions.

Laurent



> Le 6 janv. 2021 à 07:12, Arnaud  a écrit :
>> 
>>> Le 21 déc. 2020 à 07:35, Arnaud  a écrit :
>>> 
>>> Ca fait un peu trojan ce Covid. C'est peut-être pas une défaillance, mais 
>>> une fonctionnalité ? :)
>> 
>> Ben dit donc, moi qui croyais être master parano, je trouve en toi un 
>> nouveau maître à penser 8^)
> 
> Merci pour ces mots de réconfort.
> Ca me touche ;)

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] De Swisscom a Sunrise en GPON ?


> Le 6 janv. 2021 à 06:39, Arnaud  a écrit :
> 
> Je n'utilise plus les box des fournisseurs, car par expérience, les problèmes 
> viennent surtout de là.
> Et les appels que j'ai dû faire auprès des FAI, ont été pour environ 90% du 
> temps, un problème de changement de config sur la box fait par un technicien, 
> reset de la box demandé par le support, etc.
> Donc, je ne place pas mon propre routeur en face de la box, mais je le 
> remplace ^^
> 

C’est 2 réponses possibles, je suppose. Soit on considère qu’on ne veut pas de 
leurs box chez soi. Soit on considère que leurs box sont des extensions de leur 
réseau (c’est leur affaire), et on leur donne un coin de notre espace. Il y a 
du pour et du contre dans les 2 cas… tant qu’ils ne mettent pas des micros ou 
des caméras dans leur box, ou une entourloupe de ce genre.



> Ce que j'ai constaté dernièrement, voici une partie:
> 
> * chez un fournisseur, les logs d'appels/réceptions sont incomplets (certains 
> appels ne sont pas logués en fonction de certains critères). 
> Après signalement, ça s'est amélioré
> 
> * chez un autre fournisseur, les logs d'appels entrants ne sont pas logués, 
> et d'après leur support c'est parce que c'est interdit par la loi ^^
> Donc on peut avoir les appels sortants, mais pas ceux qui ont appelés, c'est 
> bizarre je trouve.
> 
> * chez encore un autre, les appels entrants sont obfusqués, même si ce n'est 
> pas un numéro masqué
> Par contre, on peut les faire apparaitre par certains procédés (je trouve 
> personnellement marrant)

Ce serait bien de savoir quelle est la logique derrière tout ça. Peut-être que 
c’est vrai qu’ils ont eut des histoires avec la protection des données, mais 
c’est une explication parmi d’autres explications possibles.
> 
> L'obfuscation de numéros entrants est récent d'après ce que j'ai vu, Ca m'a 
> fait penser à une protection des appels marketing ^^

C’est mal de penser à mal, mais des fois on tombe juste….

> D'ailleurs, c'est différent aussi sur les logs de numéros de portable. En 
> fonction si c'est un abonnement ou un prépayé

C’est quand même curieux qu’ils fasse ça. Bon, pour les appels sortants, ils 
ont intérêt à être précis, puisque le modèle de facturation dépend toujours des 
personnes appelées.

> 
> J'ai pas encore fait de listing de problèmes par fournisseur, mais je peux.
> Ils aiment déjà généralement pas quand je les appelle, je suis pas sûr que ça 
> va me faire monter dans leur estime ^^

Ca aurait en effet plus d’impact si c’était connu.
> 
> Mais bon, j'ai fait des parsers de logs, donc je surveille ^^

Je ne m’étais jamais vraiment intéressé à la question jusqu’ici. Qu’est-ce qui 
t’avait intéressé à la chose ?

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] De Swisscom a Sunrise en GPON ?


> Le 5 janv. 2021 à 19:36, Arnaud  a écrit :
>> 
> 
> Ok, en 20 ans d'ADSL/fibre, il n'y a qu'un seul technicien qui est venu et 
> c'était pour poser la prise OTO :)
> Vous avez quoi comme problème généralement pour faire appel à un technicien 
> aussi régulièrement ?
> 

Ca dépend du mode opératoire. De nos jours, la pratique est de faire installer 
une « box » par le FAI, donc chaque fois qu’il y a changement de technologie, 
on risque de voir le technicien. Dans les cas simples (plug’n play), on reçoit 
la boîte par poste. Mais s’il y a quelque chose d’un peu difficile, la pratique 
est de les laisser faire. D’autant qu’ils travaillent au forfait, donc c’est 
mieux que de batailler pour un temps X qui peut aller entre 2 minutes jusqu'à 
une demi-journée… Autant laisser faire les gens qui ont l’habitude.

Bien sûr, il faut avoir son propre routeur placé en face de la box, pour a) 
garder sa propre configuration intacte b) ne pas exposer son LAN… mais là je 
prêche à des convaincus :-)

> Par contre, les problèmes que j'ai constatés sont surtout sur les logs 
> d'appels des FAI principaux actuellement.
> 
> _

Je suis curieux… de quoi s’agit-il avec les logs d’appels?
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] De Swisscom a Sunrise en GPON ?

Intéressant en effet, cette différence d’approche entre France et Suisse… qui 
en dit long sur les coutumes politiques/économiques des deux pays.

En Suisse — si j’ai bien compris — on choisit la simplicité (on fait en soft au 
lieu d’envoyer quelqu’un brancher un cable), mais ça prend du temps…  Il y a 
peut-être aussi cette attitude en Suisse qui consiste à dire que si quelqu’un a 
dit qu’il allait le faire, ça va se faire tôt ou tard, sauf evènements 
exceptionnels. Et qu’au pire on vous filera le numéro de portable du 
technicien; qui vous répondra, vu que c’est rare qu’on le dérange (puisque ça 
marche en général et que les gens n’appelle pas trop pour vérifier). Et comme 
c’est lui a la compétence, il va vous répondre.

Alors qu’en France ça se perd parfois dans les méandres, il faut toujours 
téléphoner trois fois. Et comme les gens appellent tout le temps pour se 
plaindre, il faudra passer par un opérateur lambda du 
méga-centre-d’appel-du-centre-de-la-galaxie, et on aura rarement affaire à un 
technicien sur le terrain — sauf si on passe par la voie informelle.

Je caricature, mais c’est un peu l’esprit…

Laurent



> Le 5 janv. 2021 à 09:46, Frédéric Dumas  a écrit :
> 
> 
> Merci Laurent pour ta réponse,
> 
> D’après mes amis, leur accès Internet Sunrise est tombé en marche après mon 
> départ. A priori, il suffisait d’attendre pour que se synchronisent l’ONT 
> chez eux et l’OLT dans la rue.
> 
> Les fibres GPON mutualisées entre plusieurs opérateurs sont une nouveauté 
> pour moi. En France, la fibre GPON n’est allumée que pour un seul opérateur à 
> la fois. Quand on en change, un technicien doit débrancher la fibre du client 
> de l’OLT de l'ancien opérateur et la rebrancher sur celui du nouvel 
> opérateur, dans l’armoire de répartition dans la rue. Il n’y a pas de période 
> de recouvrement, pendant laquelle les deux opérateurs sont simultanément 
> accessibles sur la même fibre. En Suisse, il semble qu’une fibre soit 
> mutualisée entre plusieurs opérateurs. Du coup les temps de synchro ONT-OLT 
> au branchement semblent nettement plus longs.
> 
> 
> --
> Frédéric Dumas
> f.du...@ellis.siteparc.fr
> 
> 
> 
> 
>> Le 30 déc. 2020 à 08:14, Laurent Franceschetti  a 
>> écrit :
>> 
>> Bonjour Frédéric,
>> 
>> Peu d’expérience avec la fibre, car je suis toujours resté chez Swisscom 
>> depuis que je l'ai. 
>> 
>> Je ne sais pas si ma réponse est très utile, mais elle constitue un « 
>> workaround » : toujours considérer le boitier du fournisseur d’accès comme 
>> une boîte noire (avec uniquement un cable Ethernet qui arrive dedans depuis 
>> notre routeur) càd comme une extension de l'opérateur... et laisser 
>> l’opérateur se débrouiller avec. Sauf erreur, on paie le même prix qu’un 
>> installateur vienne ou non, donc autant avoir le service pour lequel on paie 
>> ?
>> 
>> Rien n’empêche, ensuite, de « cuisiner » gentiment le technicien, pour avoir 
>> la réponse à ta question :-)
> 
> 
> 
> 
> 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] EU: 145 milliards pour la recherche sur les microprocesseurs

2021-01-02 Par sujet Laurent Franceschetti

Et en effet, il me semble que les révolutions industrielles sont toujours 
parties de a) innovation b) entrepreneurs, et non de gouvernements. La seule 
chose sur lesquelles ces derniers pouvaient agir était c) l’environnement.

Le gouvernement chinois gère beaucoup de choses, sauf l’esprit d’entreprise. Et 
pour cause. Ils ont l’air d’avoir compris pourquoi le communisme avait échoué 
(on n’insuffle pas la vie à l’économie depuis le haut).

Pour la question précise, je n’y connais pas grand chose en microprocesseurs, 
sauf que c’est un milieu assez fou, qui a un point commun avec l’agriculture: 
les produits deviennent vite périmés. Au passage, je n’ai pas tout à fait la 
compréhension de pourquoi notre société a tellement besoin de courir à donf 
vers les 2nm. Je ne suis pas contre, mais franchement, est-ce qu’on n’a pas 
fait des progrès gigantesques dans ce domaine, que le software mettra des 
années à rattraper ? Quel est le « driver » de la course au 2nm ? 

Bref, si on a des priorités à mettre dans l’investissement au niveau d’un 
continent, est-ce que c’est là que cela devrait aller ? Ou alors y aurait-il 
des choses plus urgentes ? 



> Le 3 janv. 2021 à 01:07, Philippe Strauss  a 
> écrit :
> 
> Par contre ce qui est à craindre c’est que NXP et Infineon en soient les 
> grands bénéficiaires, avec des miettes pour les plus petites boîtes.
> 
> QUI SE LANCE AVEC MOI DANS UNE STARTUP ALA ARM, EN COMMENCANT AVEC LE RISC-V?
> 
> (Je suis réellement partant! :-)

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] EU: 145 milliards pour la recherche sur les microprocesseurs

2021-01-02 Par sujet Laurent Franceschetti


> Le 2 janv. 2021 à 18:32, Daniel Cordey  a écrit :
> 
> 
> Ce qu'il y a est que, bien que cette décision soit basée sur un fait avéré, 
> comme la part de 10% du marché, cette décision n'est pas basée sur des faits, 
> mais sur une volonté. Ce qui est choquant est qu'il n'y ait aucune 
> démonstration de la stratégie ni d'objectifs à atteindre. Or, pour avoir été 
> impliqué une fois dans ce genre d'analyse, on s’aperçoit que gagner ne fusse 
> qu'un seul pour cent de part de marché implique des efforts importants et une 
> stratégie complexe et coordonnée. Or, ici, pas d'objectif de part de marché, 
> pas d'explications sur quel marché, quel débouché, etc. Donc, on va arroser 
> plein d'entités avec 145 milliards d'Euros, mais on ne semble attendre aucun 
> résultat... C'est assez hallucinant.
> 

Dans cette description, je reconnais le « volontarisme » :

> Tendance à croire (notamment en politique) que la volonté humaine est capable 
> d'imposer le changement; thèse, tendance selon laquelle la volonté humaine 
> l'emporte sur toutes les autres facultés, sur le réel, sur les événements, 
> dans l'État et la société. (TiLF 
> )


Ceux qui croient qu’il n’y a qu’à arroser avec suffisemment de flouze quelque 
part, pour tout réussir. La réalité ne marche pas ainsi. On peut acheter les 
meilleurs ingrédients pour un plat, si la recette n’est pas la bonne ou mal 
exécutée, on ne fera qu’amplifier le sentiment d’échec.

J’ai vu le volontarisme un peu partout, y-compris dans les directions 
bancaires. La vérité de base est que soit on réussit à rassembler les équipes 
compétentes avec les infrastructures nécessaires, soit il ne se fera rien. 
Quand à l’idée que c’est le monde universitaire qui fournir la colonne 
vertébrale du développement, on rêve complètement. L’université ou l’EPFL sont 
faites pour former les gens ou faire de la recherche fondamentale. L’université 
n’est pas la vie réelle. Et les « parcs technologiques » se révèlent souvent — 
en définitive — des pépinières financées par l’Etat, qui sont exploitées sans 
frais et sans risques par les multinationales. 

Ce sont les « vrais » projets, conduits par des vrais entrepreneurs dans la vie 
réelle qui font les succès industriels. Donc oui, j’aurais des réserves 
vis-à-vis de cette injection de flouze qui risque de finir dans les égouts, ou 
pire, dans la poche d’actionnaires de multinationales — qui, ironie suprême, 
finiraient par rafler toutes les initiatives en perdition à peu de frais et 
exporter les profits en dehors de l’UE, vers les US ou la Chine….___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] EU: 145 milliards pour la recherche sur les microprocesseurs

2021-01-02 Par sujet Laurent Franceschetti


> Le 2 janv. 2021 à 14:54, Daniel Cordey  a écrit :
> 
> 
> Soyez critiques, interrogez-vous et ne vous ruez pas sur n'importe quelle 
> nouvelle qui vous semble extraordinaire, simplement parce que cela comblerait 
> nos fantasmes d'Européens... et essayons d'être efficace et réalistes avant 
> tout :-)
> 

Note bien, que je n’ai exprimé aucune opinion à ce sujet. Je me suis contenté 
de fournir le document officiel qui avait servi de source à l’article du 
journal… Plus le temps passe et plus je me demande à quoi servent les journaux, 
qu’ils soient imprimés ou en ligne.

Et on constate que leur éthique professionnelle ne s’est pas améliorée. Ils ne 
fournissent jamais leurs sources, même quand ce sont des communiqués de presse 
disponibles sur Internet. Un petit hyperlien sur le site de la Commission 
européenne, ça n’aurait pas coûté cher...

Est-ce que si ces « médias » fournissaient leurs sources, les lecteurs 
comprendraient sans doute combien leurs articles sont superficiels ? Et ces 
mêmes lecteurs apprendraient à aller à la source, au lieu de lire la daube de 
gens qui ne font que tu copier/coller ?
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] EU: 145 milliards pour la recherche sur les microprocesseurs

2021-01-01 Par sujet Laurent Franceschetti

Voici le communiqué de presse officiel de la Commission européenne, avec le pdf 
de la déclaration complète:
https://ec.europa.eu/digital-single-market/en/news/joint-declaration-processors-and-semiconductor-technologies
 





> Le 1 janv. 2021 à 23:35, Philippe Strauss  a 
> écrit :
> 
> https://www.eetimes.eu/eu-signs-e145bn-declaration-to-develop-next-gen-processors-and-2nm-technology/
> 
> 
> --
> Tempted in our minds
> Tormented inside lie
> Wounded and afraid
> Inside my head
> Falling through changes
>-- Portishead
> 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] De Swisscom a Sunrise en GPON ?

Bonjour Frédéric,

Peu d’expérience avec la fibre, car je suis toujours resté chez Swisscom depuis 
que je l'ai. 

Je ne sais pas si ma réponse est très utile, mais elle constitue un « 
workaround » : toujours considérer le boitier du fournisseur d’accès comme une 
boîte noire (avec uniquement un cable Ethernet qui arrive dedans depuis notre 
routeur) càd comme une extension de l'opérateur... et laisser l’opérateur se 
débrouiller avec. Sauf erreur, on paie le même prix qu’un installateur vienne 
ou non, donc autant avoir le service pour lequel on paie ?

Rien n’empêche, ensuite, de « cuisiner » gentiment le technicien, pour avoir la 
réponse à ta question :-)

Cordialement,
Laurent




> Le 29 déc. 2020 à 22:51, Frédéric Dumas  a écrit :
> 
> Bonjour à tous,
> 
> quelques heures avant de prendre un train, des amis m’hébergeant à Zurich me 
> demandent de recâbler leur box Internet: avec la nouvelle année, ils passent 
> de Swisscom à Sunrise, ils ont reçu et déballé les nouveaux équipements, ils 
> aimeraient bien que ce soit moi qui débranche les anciens et rebranche les 
> nouveaux (en pratique, qui élague la forêt de câbles).
> 
> Et ça ne s’est pas bien passé. A cause du train, on n’a pas pu creuser avec 
> le support technique. Mais quelqu’un aurait-il un avis ?
> 
> 
> Ils ont une arrivée optique en GPON dans le mur, j’imaginais que tous ces ONT 
> s’auto-provisionnent: il suffit de les brancher pour qu’ils retrouvent leurs 
> timeslots et leurs VP/VC sur une fibre multi-opérateurs.
> 
> J’avais tort. Le wi-fi et l’interface d’administration de la nouvel box 
> Sunrise fonctionnaient évidemment, mais la patte WAN est restée désespérément 
> down. Bien sûr, le bon branchement de la jarretière optique a été vérifiée 
> (du LC/APC dans le mur, du LC/UPC sur la box Sunrise, de mémoire).
> 
> Mais la blague devient mauvaise quand le retour arrière est lui aussi un 
> échec. L’ancienne box Swisscomm avec son ancienne jarretière optique, ne voit 
> aucun signal elle non plus. Alors qu’elle fonctionnait parfaitement une 
> demi-heure avant.
> 
> Quand on passe d’un opérateur fibre à un autre en Suisse, comment faut-il 
> procéder ?
> 
> Merci.
> 
> --
> Frédéric Dumas
> f.du...@ellis.siteparc.fr
> 
> 
> 
> 
> 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Code source du vaccin BioNTech/Pfizer

> 
> Le 29 déc. 2020 à 17:29, Pierre Maitre  a écrit :
> 
> Merci à Alain Borel et à Marc Schaefer pour leurs considérations
> pertinentes que je partage tout à fait.
> Je me permets de rebondir sur l'aspect "informatique" du vaccin à ARN
> messager. En effet, si la méthode est nouvelle et suscite, du fait de
> cette nouveauté, une certaine crainte dans la population, elle est
> aussi révolutionnaire dans le sens qu'elle va simplifier grandement la
> fabrication des nouveaux vaccins à venir  et raccourcir  le délai
> entre la conception d'un vaccin et sa mise sur le marché. 

J’apprécie qu’un médecin parle de son expérience. Il ne faudrait toutefois pas 
ramener tout échange à des soi-disant « craintes de la population », car cela 
empêcherait un débat rationnel.

Notons que je peux comprendre que beaucoup de gens soient obnubilés en ce 
moment par le vaccin COVID-19. Mais ce n’est qu’un phénomène transitoire, et 
secondaire dans notre discussion. La question n’est donc pas, il me semble, de 
savoir si le vaccin COVID-19 fonctionne ou non, ou s’il est utile ou non, ou si 
la "population" le craint ou non. 

La question est d’une tout autre ampleur: elle concerne le modèle d’affaires de 
l’industrie pharmaceutique qui semble profiter trop des aides de l’Etat pour 
enrichir des actionnaires, et le parallèle qu’on pouvait en tirer avec le monde 
du Logiciel Libre. Notons au passage, que les objections que je formule à ce 
modèle d’affaire a) ne sont pas d’ordre médical et b) sont plutôt typiques de 
l’industrie financière.

Elles ont trait à la durabilité de la politique d’investissement de l’Etat et 
au rôle disproportionné que prennent les brevets dans la politique des sociétés 
cotées en bourse. À cela (pour les idéalistes) je rajouterais les craintes de 
volatilité des actions des pharmas, car le risque pour les investisseurs est 
devenu trop important. En bref, le système a besoin d’être réformé parce qu’il 
est devenu trop instable et imprévisible au niveau financier. Du coup, cela 
vaut la peine de revenir à une réflexion sur les modèles d’affaires.







___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Normalisation des noms de fichiers et dossiers

> Le 29 déc. 2020 à 17:35, Pierre Maitre  a écrit :
> 
> 
> DESCRIPTION
> The detox utility renames files to make them easier to work with.  It
> removes spaces and other such annoyances.  It'll also translate or
> cleanup Latin-1 (ISO 8859-1) characters encoded in 8-bit ASCII, Unicode
> characters encoded in UTF-8, and CGI escaped characters.


Très intéressant ! Ca fait en effet ce qui est demandé, et peut-être même trop 
bien. Pour revenir à la remarque de Marc, est-ce que les utilisateurs vont être 
contents, si on leur sabre leurs espaces et leurs caractèrs accentués ? De nos 
jours, les espaces ne devraient plus être un problème.

Mais je pense que comme tout bon utilitaire, detox doit être configurable?...
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Normalisation des noms de fichiers et dossiers



> Le 29 déc. 2020 à 17:18, Marc SCHAEFER  a écrit :
> 
> 
> D'un autre côté, les utilisateurs vont-ils aimer voir leurs répertoires
> et fichiers changer de nom ? :)


C’est une question « profonde » mais la question des noms de fichiers qui « 
bloquent » à la synchro est tout à fait concrète et elle devrait être abordée. 
C’est vrai qu’il faudrait d'abord se mettre d’accord sur une approche, pour 
éviter les controverses, ou les erreurs fatales.

Ce qui veut dire se poser la question du « PGCD » du charset  entre les 
différents OS (Linux, MacOS, Windows, etc.) et les différents outils de synchro 
(NextCloud, TresorIt, SecureSafe...). Ou alors avoir des PCGD pour chaque type 
d’outil de synchro.

Il y aurait donc un certain de réflexion à faire, avant de se lancer dans du 
renommage. Mais si la doctrine est claire, et le résultat prévisible, je pense 
que les utilisateurs n’auront pas d’objection à ce qu’on renomme leurs fichiers 
qui seraient « non-conformes ». Au fond, s’ils ne veulent pas que leur document 
soit renommé d’office, il faudra qu’il soit conforme dès le départ… :-)


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Normalisation des noms de fichiers et dossiers




> Le 29 déc. 2020 à 17:06, Samuel Chenal  a écrit :
> 
> Hello !
> 
> L'un d'entre vous aurait-il un script pour "normaliser" les noms de
> fichiers et de dossiers ?

C’est un problème auquel j’ai eu passablement l’occasion de penser ! Pour ma 
part, j’avais besoin de mettre une date dans le nom du document.
Je suis parti sur un package python (qui est un langage puissant avec un 
parseur de ligne de commande puissant, et qui sait « auto-installer » des 
commandes).

> 
> Sur GNU/Linux, ou sur MacOSX, on peut mettre un peu se qu'on veut comme
> nom de fichiers/dossiers, mais dès qu'on doit les transférer via Samba
> ou sur un file system plus basique, on est souvent coincé. Et même si on
> reste dans GNU/Linux, on est souvent embêté avec certains caractères
> spéciaux ou réservés (comme le ? ou les espaces).
> 
> Ce que j'aimerais faire, c'est lancer un script qui renomme les fichiers
> et les dossiers, en remplaçant les caractères réservés par un autre, non
> réservé, comme le underscore par exemple.


Le besoin est clair.


> 
> Les caractères que j'aimerais remplacer sont ceux qui posent en général
> souci sur du FAT ou via CIFS : +*/&%?!$,'":; l'espace et les caractères
> accentués. Exemple :
> 
> Que penser de l'opéra, les concerts et autres ?.odt
> 
> --> Que_penser_de_l_opera_les_concerts_et_autres.odt
> 

Bonne idée. Il faudrait spécifier la fonction de base attendue, ainsi que les 
options possibles.

> Idéalement, il faudrait remplacer les caractères accentués par les mêmes
> caractères sans accents et supprimer les espaces, surtout ceux en début
> de nom ou en fin de nom.
> 
> Il me semble que c'est un problème assez courant, mais je n'ai pas
> trouvé de solution réellement satisfaisante sur le net. Quelqu'un
> aurait-il une commande magique ou un script bash ad hoc dans sa besace
> ?  ;-)
> 
> a+
> 

Note qu’il y a la commande rename: 
https://www.cyberciti.biz/tips/renaming-multiple-files-at-a-shell-prompt.html 
 
(il y en même 2 qui circulent sauf erreur).
Eventuellement: https://github.com/ap/rename/blob/master/rename 



Sinon, qu’à cela ne tienne ? On pourrait faire ça « proprement »? En créant un 
package sur github?

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Code source du vaccin BioNTech/Pfizer



> Le 29 déc. 2020 à 13:07, Marc SCHAEFER  a écrit :
> 
> C'est d'ailleurs pour ça que je trouve `logiciel libre' plus général
> qu'open source.
> 
> En fait, il me semble qu'à part l'informatique -- où le logiciel libre
> reste encore minoritaire -- il n'y a pas beaucoup de secteurs où ses
> principes sont appliqués.  Une des raisons est peut-être le caractère
> très simple de manipulation du logiciel, fasse à des mouvements
> mécaniques [1] ou des médicaments, et la dépendance au matériel fermé.
> 

Tout à fait d’accord. L’informatique est un bon point de référence, justement 
en raison de son "immédiateté", et du fait que les expériences sont très 
réplicables. Tout en sachant que le reste du monde ne fonctionne pas tout à 
fait comme ça...

> Même sur mon apu2 où le BIOS est libre, à ma connaissance, le firmware
> et le câblage du processeur ne l'est pas. Une informatique libre
> nécessiterait un processeur libre (*) et des périphériques libres.
> Rappelons aussi que parfois certaines normes s'opposent au libre (p.ex.
> la certification des firmware d'équipements sans-fil).

Il y a des tentatives dans ce sens, ou du moins des "allègements ». ARM n’est 
pas libre, mais a adopté une structure plus « ouverte ». 

Ou alors l’architecture PowerPC, qui elle est vraiment Open Source.

> 
> Mais bien sûr, l'impression 3D et les imprimantes à ADN pourraient
> changer la donne et créer un besoin pour du matériel, voire code
> génétique, open source, voire libre.

En effet — peut-être que cela pourrait être une opportunité ?

> 
> Attention toutefois: les brevets agissent à un niveau complètement
> différent: un système complètement open source peut être tout de même
> menacé par des brevets [2] -- avec plusieurs exemples.
> 
> En résumé, une exigence des mêmes niveaux d'ouverture que le logiciel
> pour un vaccin, aujourd'hui, s'oppose complètement à la façon dont
> l'industrie respective fonctionne.

En effet, les brevets peuvent agir de façon insidieuse.

Et ces considérations se heurtent à des décennies de pratiques fermées dans la 
pharma, où tout le modèle d’affaire dépend des brevets, pour financer la 
recherche et dégager des profits. Cela ne doit pas empêcher d'y penser et 
tâcher d’élaborer des voies à explorer. 

Au fond, le changement qu’a subi l'informatique pourrait-il être un précédent ? 
Le monde de l’Open Source s’est libéré en tirant parti de la révolution du 
microprocesseur pour casser les pratiques d’IBM et des constructeurs 
traditionnels. Dans les années 1970, la situation paraissait assez desespérée — 
aujourd’hui même IBM a en partie accepté le principe de l’Open Source.

> 
> Mais j'ai trouvé particulièrement intéressante l'analyse `à la' open
> source des codons du vaccin. C'est peut-être la première fois que des
> `makers' s'intéressent à ça ainsi.
> 
> 

En effet, ça ouvrirait peut-être des portes ? Ce qu’il faudrait idéalement, 
c’est une révolution technologique du même type que le microprocesseur... Ou 
tout d’un coup des gens dans un « garage » ou des Linus Torvalds de la biologie 
pourraient amener de la « disruption » dans la grande industrie multinationale 
(et monopolistique), qui est restée encroutée dans des pratiques dépassées ?

Cela vaudrait la peine, en tout cas, de considérer la chose ?

Bonne journée,
Laurent


___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Code source du vaccin BioNTech/Pfizer

Je pense que c’est un sujet intéressant, parce qu’il nous permet de réfléchir, 
par effet de miroir, à ce qui fait les spécificités de l’Open Source, notamment 
dans le logiciel.



> Le 29 déc. 2020 à 11:28, Marc SCHAEFER  a écrit :
> 
> Dans ce cas précis, une partie des recherches covid-19 a été mise
> à disposition à la communauté: p.ex. le séquençage du virus par
> les Chinois [1].

Open Source, signifie « open source » — les bonnes pratiques sont claires. Tous 
les éléments techniques et légaux doivent être mis à disposition pour une 
utilisation libre (dans les limites de la licence).

> 
> Beaucoup de recherches ont été mises en libre accès, y compris par
> les horribles éditeurs.
> 
> Effectivement, il y a des mouvements pour mettre les vaccins dans le
> domaine public [2].

En effet c’est significatif.

> 
> Et je trouve intéressant cette analyse du code du vaccin: j'espère juste
> que la magouille pour passer outre le système immunitaire (molécule PSI
> remplaçant une autre) ne sera pas trouvée par un virus :->
> 
> C'est une interprétation politique. Pour se faire un second avis,
> médical cette fois, écouter par exemple cette vidéo:
> 
>   https://www.youtube.com/watch?v=xmGaLM6ltW8
> 
> En deux mots: aucun raccourci n'a été effectué, et les tests effectués
> sur des dizaines de milliers personnes montrent que le vaccin est
> efficace. La vaccinovigilance continue et les instructions seront
> adaptées au fur et à mesure que des contre-indications rares
> apparaissent.
> 
> Voir aussi ce schéma: 
> 
>   https://pbs.twimg.com/media/EqRjzCFXUAs71Rc?format=jpg&name=large 
> 
C’est là la différence fondamentale avec le logiciel. Avec le logiciel a) nous 
connaissons un peu le sujet b) on peut facilement vérifier les affirmations, en 
faisant des tests.

Vu que nous ne sommes pas (dans l’ensemble) ni médecins ni biologiste et 
incapables de tester l’information qui nous est fournie, il est imprudent de 
rentrer dans les questions médicales ou biologiques. Si A fait de la science, 
mais que B ne peut pas vérifier ce que dit A mis à part citer de la littérature 
ou des autorités, alors tout ce que dira B sera des opinions.

Dès lors affirmer entre nous que le vaccin ne marche ou ne marche pas, dans ces 
conditions, serait du débat d’opinions (non-scientifique), agrémenté 
d’arguments d’autorité.

En revanche, chacun de nous est légimité à avoir des avis moraux ou idéaux, et 
les exprimer.

Indépendamment de savoir si les tests ont été suffisants ou non (ce que seul 
des spécialistes pourraient évaluer et qui a fortiori ne sera certain que dans 
quelques mois voire quelques années), on peut discuter pour savoir s’il était 
justifié d’appliquer des procédures politiques et administratives d’urgence. Si 
on parle de principe de précaution, il faut se garder, en testant des 
médicaments, non seulement de ce que nous ne savons pas, mais de ce que nous ne 
savons pas que nous ne savons pas.
 
Ceci est valable pour le logiciel. Mais voilà, pour le logiciel, les phénomènes 
se déroulent à des vitesses extrêmement rapides, et la probabilité qu’un défaut 
se révèle après la première seconde, minute, heure, jour, etc. décroît 
exponentiellement.

Il n’en va pas de même pour les processus biologiques humains, et à fortiori 
les écosystèmes. Donc on peut dire tout ce qu’on veut qu’on a testé, 
contre-testé et sur-tester, on ne peut pas gagner du temps sur les processus 
biologiques et les écosystèmes.

Tout cela pour dire que de vouloir comparer, la publication d’une partie des 
recherches sur le COVID-19 à du logiciel open source est une métaphore qui ne 
tient pas vraiment la route. 

Tout le modèle d’affaires de la grande industries pharmaceutique est fondé sur 
les brevets.

Je ne me suis pas trop inquiété quand Microsoft a repris github — parce que 
justement nous étions capables de tester et évaluer le comportement de github. 
Mais pour le moment, tous ces jolis schémas sur les vaccins COVID-19 sont pour 
nous des actes de foi, car nous ne pouvons pas vérifier si a) le schéma 
correspond vraiment à ce que cela devrait être légalement b) le schéma est 
effectivement appliqué dans la pratique c) le schéma n’omet pas des éléments 
qui seraient essentiels pour comprendre le système.


La prudence est d’être comme Saint-Thomas. Si on ne fait pas confiance à 
Microsoft, a fortiori on ne verrait pas comment on pourrait faire confiance à 
Pfizer — qui a déjà eu plusieurs affaires judiciairs graves au passage non pas 
pour abus de position de marché, mais pour fraude contre la santé publique 
(voir affaire du Département américain de la justice 

 en 2009). Et à en croire un article de Bloomberg de l'époque Pfizer étaient 
des multirécidivistes

Re: [gull] Code source du vaccin BioNTech/Pfizer

Bonjour Pierre-Olivier,

J’avoue que je reste un peu sceptique. Livrer une partie du code, ne veut pas 
nécessairement dire que le code soit libre (il est sous brevet!) et que Pfizer 
ait été particulièrement transparente. Bien que l’image puisse être inexacte, 
cela m’évoque un fournisseur de logiciel propriétaire qui publie le code code 
du client sur github. Cela reste du closed-source.

https://inthesetimes.com/article/pfizer-covid-vaccine-world-trade-oganization-intellectual-property-patent-access-medicines

Peut-être que je suis trop soupçonneux, mais je vois là une opération de 
relations publiques pour se mettre artificiellement dans les bonnes grâces des 
informaticiens — alors que l’industrie pharmaceutique, entièrement fondée sur 
les brevets et le secret, est complètement aux antipodes des idéaux de l’Open 
Source.

Quelques recherches sur le web, montrent une quantité de matériel qui remet en 
question la nature « free »  
(parfois
 gratuit mais non libre) des vaccins. Le problème n’est pas les vaccins en soi, 
mais le modèle d’affaires.

D’autre part (mais c’est un autre sujet): personne ne sait encore si le vaccin 
de Pfizer sera a) vraiment efficace et b) il n’aura pas d’effets secondaires. 
Ceci d’autant que beaucoup de garanties et procédures pour l’autorisation de 
médicaments sont passées par-dessus bord, également en Suisse (voir art. 3 de 
la loi COVID-19, 
 qui 
fera l’objet d’un référendum).

Bonne journée,
Laurent


> Le 29 déc. 2020 à 10:41, Pierre Maitre  a écrit :
> 
> Bonjour à tous
> 
> Le "code source" du vaccin BioNTech/Pfizer expliqué aux informaticiens:
> 
> https://berthub.eu/articles/posts/reverse-engineering-source-code-of-the-biontech-pfizer-vaccine/
> 
> En quelque sorte, c'est presque du logiciel libre, donc même si c'est
> un peu hors sujet, ça ne l'est pas trop!
> 
> Pierre-Olivier Maitre
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Helas Telegram fait de meme (Linkedin decide pour vous !)

2020-12-07 Par sujet Laurent Franceschetti

Merci de l’idée du tableau récapitulatif, très utile !

Pour ceux qui ne sauraient pas (ce qui inclut le soussigné jusqu’à ce matin), 
la licence Affero (APGL) a une clause additionnelle par rapport à la GPL:
> La licence publique générale GNU Affero est basée sur la GNU GPL, mais a une 
> clause additionnelle qui autorise les utilisateurs interagissant avec le 
> logiciel sous licence via un réseau à recevoir les sources de ce programme. 
> Nous vous recommandons d'envisager l'utilisation de la GNU AGPL pour tout 
> logiciel exécuté sur un réseau. La version 3 est la plus récente.
https://www.gnu.org/licenses/licenses.html#AGPL 


Donc le choix de Signal prend tous son sens. C’est pourquoi je recommenderais, 
plutôt que d’écrire "oui », dans les colonnes respectives, d’écrire le cas 
échéant la licence appliquée. Pour d’autres paramètres potentiellement 
intéressants:

- cryptage de la communication client-serveur
- cryptage end-to-end (autrement dit, impossibilité pour le serveur de 
décrypter le message)


> Le 7 déc. 2020 à 13:05, Marc SCHAEFER  a écrit :
>> 
> 
> Je suis d'accord, voici ma synthèse:
> 
> nom protocoleserveur  clientclient web?   lien
>documenté?   libre?   libre?  contacts?
> ---
> IRC oui  oui  oui   oui   non
> Matrix  oui  oui  oui   oui   non
> Signal  oui  oui  oui   oui   oui, hash
> Telegram oui?non  oui   oui   oui?
> Whatsapp non non  non   oui   oui!

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Helas Telegram fait de meme (Linkedin decide pour vous !)

2020-12-07 Par sujet Laurent Franceschetti

Signal a l’avantage d’être une plate-forme open source (voir entrepôt sur 
github  en licence GNU Affero 3.0), donc il ne 
faudrait pas la mettre dans le même panier que les autres. Ce serait dommage de 
confondre « amis » et « adversaires ».

Dans ma compréhension, Signal a aussi l'avantage d’être judicieuse et claire 
sur le protocole qu’elle utilise pour les numéros de téléphone, qui n’est 
utilisé que pour la double authentification (l’appareil lui-même). Ce ne sont 
pas les numéros de téléphone qui sont stockés, mais des hashs. Pour le reste, 
c’est l’utilisateur qui se débrouille avec son propre carnet d’adresse.

Pour « l’auto-découverte », c’est les hash des numéros de téléphone qui sont 
envoyés au serveur, et non les numéros eux-mêmes:

> Signal periodically sends truncated cryptographically hashed 
>  phone numbers for 
> contact discovery. Names are never transmitted, and the information is not 
> stored on the servers. The server responds with the contacts that are Signal 
> users and then immediately discards this information. Your phone now knows 
> which of your contacts is a Signal user and notifies you if your contact just 
> started using Signal. 

Source: 
https://support.signal.org/hc/en-us/articles/360007061452-Does-Signal-send-my-number-to-my-contacts-

> Le 7 déc. 2020 à 11:32, Marc SCHAEFER  a écrit :
> 
> On Mon, Dec 07, 2020 at 10:22:06AM +0100, Miçhael Parchet wrote:
>> Télégramme tout comme signal ou permet instantanément de savoir lesquels de 
>> vos contacts ont la même application sans avoir besoin d???inviter qui que 
>> ce soit
>> Qu???est-ce qui ne va pas dans ce principe z je trouve que ça va mieux que 
>> WhatsApp où on doit faire une invitation ou non ?
>> Quel est votre avis ?
> 
> Déjà, associer un numéro de téléphone à une application de messagerie me
> gêne (principe de Whatsapp, aucune idée si c'est le principe de Signal
> ou Télégram).
> 
> Ensuite donner mes contacts à Signal ou Télégram (car sinon comment
> sauraient-ils) est également gênant.
> 
> Toujours le grand problème de sécurité vs utilisabilité ...
> 
> [ 20 lignes citées inutilement supprimées ]

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Helas Telegram fait de meme (Linkedin decide pour vous !)

2020-12-06 Par sujet Laurent Franceschetti

Telegram (en plus de Whatsapp) est donc à proscrire?... Dans ma liste des apps 
de chat, ne reste que Signal. Ils n’ont pas de base centralisée de contacts.

https://support.signal.org/hc/en-us/articles/360007061452-Does-Signal-send-my-number-to-my-contacts-
 


J’ai passablement du succès dans la migration, vu d’ailleurs que ça devient 
plus ou moins un standard, y-compris au niveau de l’Union européenne:
https://joinup.ec.europa.eu/collection/open-source-observatory-osor/news/signal-messaging-service
 


Bonne journée,
Laurent








> Le 5 déc. 2020 à 23:13, Frédéric Dumas  a écrit :
> 
> 
> Bonsoir Daniel,
> bonsoir à tous,
> 
> 
>> Il y a bien les infos normales me concernant, mais aussi des infos du style 
>> "xxx a aimé ceci..." et "xxx a commenté ceci...". 
> 
> 
> Veux-tu préciser qui est « xxx » ? Toi-même ou une autre personne ?
> 
> 
> Si LinkedIn invente des « like » ou des « share » publiés à ton nom et montre 
> aux autres ces fausses nouvelles dont tu serais soit-disant l’auteur 
> à-ton-insue-de-ton-plein-gré, effectivement c’est choquant et ça vaudrait le 
> coup de prendre quelques photos d’écran. Mais à la lecture de ton mail, il 
> n’est pas évident que c’est exactement ça que tu as observé et voulu décrire.
> 
> Un peu dans la même veine, je signale à tous cet autre comportement décevant, 
> de l’application Telegram cette fois-ci.
> 
> L’application installée sur un Linux Mint et un OS.X s’est d’abord très bien 
> comportée, me laissant ajouter un à un les contacts que je souhaitais y 
> importer, assez peu en réalité. Pendant plusieurs mois, j’ai ainsi vu les 
> contacts ajoutés sur une machine apparaitre automatiquement sur l’autre. 
> Classique synchronisation par les serveurs de l’éditeur.
> 
> Puis je l’ai installée sur mon mobile. Et là, Télégram a extrait et uploadé 
> vers « le cloud » tous les contacts présents dans le téléphone, sans que 
> l’utilisateur n’ait à donner son autorisation ni n’en soit même averti. C’est 
> le comportement par défaut de l’application. Il y a bien un paramètre pour 
> retirer son accord, mais on le cherche et on le trouve après coup… quand 
> l’application a déjà pris la décision à la place de l'utilisateur.
> 
> C’est quand j’ai vu des dizaines de noms supplémentaires de contacts, avec la 
> graphie personnelle que je leur avais donné, commencer à surgir 
> automatiquement dans l’application Telegram installée sur les machines Mac et 
> Linux, que j’ai compris qu’il m’avait siphonné le carnet d’adresse de mom 
> mobile. Il a récupéré des centaines de noms et de numéros de téléphone, et 
> désormais me les affiche sur toutes mes machines quand ces correspondants 
> sont eux-mêmes connectés.
> 
> Certains trouveront ça très pratique, « c’est le progrès ». Mais tant que 
> l’application ne demande pas l’accord de l’utilisateur, ça n’a rien d’un 
> progrès, c’est comme prendre son carnet d’adresse à quelqu’un et le lui 
> photocopier de A à Z. Je ne dirai pas ça, si nous ne savions pas que hélas, 
> sociétés et gouvernements font ce qu’ils veulent de ces données, une fois 
> aspirées dans « le cloud ».
> 
> Je serai curieux de savoir ce que disent les conditions d’utilisation de 
> Telegram sur ce point là, et particulièrement sur l’usage que la société 
> s’autorise à faire de ces centaines de millions de détails personnels (qui 
> connait qui) acquis sans vergogne. Elle est maintenant basée à Singapour 
> parait-il, le droit local doit leur y être bien favorable.
> 
> 
> --
> Frédéric Dumas
> f.du...@ellis.siteparc.fr
> 
> 
> 
> (Note pour Marc: ne pas lire au-delà :-)
> 
> 
>> Le 5 déc. 2020 à 20:13, Daniel Cordey  a écrit :
>> 
>> Bonjour,
>> 
>> Je viens de voir quelque chose qui m'effare et va sans doute tous nous 
>> concerner. Voici ce que je viens de découvrir :
>> 
>> Depuis le compte Linkedin de ma femme, j'ai eu envie de voir ce qui 
>> s'affichait lorsque l'on consultait mon compte sur Linkedin, et ce que j'y 
>> ai découvert m'a sidéré. Il y a bien les infos normales me concernant, mais 
>> aussi des infos du style "xxx a aimé ceci..." et "xxx a commenté ceci...". 
>> Or, je n'ai pas utilisé Linkedin depuis presque 2 ans et n'ai jamais fait de 
>> commentaire ou "liké" dans Linkedin (surtout pas). Je constate que :
>> 
>> - Je n'ai jamais vu ni consulté les articles mentionnés.
>> 
>> - Ces articles ne m'intéressent pas, donc je ne vois pas pourquoi je les 
>> aurais mis en avant.
>> 
>> - Je n'ai jamais fait les commentaires prétendus (car le sujet ne 
>> m'intéresse pas)
>> 
>> En conclusion, Linkedin "anime" votre compte à votre place si vous ne le 
>> faites pas !!!
> 
> 
> 
> 
> 
> 
> 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/m

Re: [gull] Linkedin décide pour vous !

2020-12-05 Par sujet Laurent Franceschetti

La vraie question, c’est comme pour les produits de ménage du commerce: par 
quoi on remplace.
Pour l’information: aggrégateur de flux RSS et s’abonner aux sources 
importantes, y-compris officielles (éviter: la presse quotidienne, contient des 
produits toxiques!) Expérience fait, une bonne combi de flux RSS est très 
supérieure à tous les réseaux sociaux. 
Pour la boîte à savon (pour faire les discours):  un blog — de préférence en 
static HTML; wiki ou CMS aussi possibles, si Open Source.
Pour les échanges: plate-forme de chat — de préférence secure (Signal) ou 
auto-hébergée (par exemple rocket.chat); listes de discussion par email 
(éviter: Whatsapp, très toxique)
Notre équivalent du bio, c’est l’open source :-P

Bonne journée,
Laurent

> Le 5 déc. 2020 à 21:26, Paul Bartholdi  a écrit :
> 
> De telle manipulations semblent presque incroyables !
> 
> J'ai abandonné LinkedIn bien avant son rachat par M*, mais pour exactement 
> les mêmes raisons, informations personnelles (parfois vraies) provenant d'on 
> ne sait où, ou transmises à d'autres applications a priori sans rapport.
> 
> Dommage, l'idée de départ semblait bonne et pouvait rendre bien service pour 
> relier les gens selon leurs intérets.
> 
> Bon dimanche,   Paul
> 
> 
> Le sam. 5 déc. 2020 à 21:07, Guyot Vincent  > a écrit :
> Le samedi 05 décembre 2020 à 08:13:07, Daniel Cordey a écrit :
> > Bonjour,
> > 
> > A ceux qui s'époumonent à prétendre que M* a changé est est maintenant le
> > grand ami des logiciels Open-source (vous avez aussi remarqué qu'ils n'ont
> > jamais parlé de logiciels libres !), je répond que je n'y crois pas et que
> > je n'y croirai jamais. Cette entreprise fait la démonstration permanente de
> > sa duplicité et seul les crédules se laissent avoir; mais ainsi va le
> > monde...
> > 
> > Si vous désirez des informations concernant les gens, n'allez pas sur
> > Linkedin, c'est un des royaumes des informations manipulées par M*. A moins
> > que vous n'envisagiez une carrière chez M*, je ne peux que vous déconseiller
> > d'utiliser Linkedin (et tous les autres réseaux sociaux).
> 
> Entièrement d'accord.
> A+
> -- 
> Vincent Guyot
> @debian GNU linux
> ___
> gull mailing list
> gull@forum.linux-gull.ch 
> https://forum.linux-gull.ch/mailman/listinfo/gull 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Linux sur des iMac légal ?

2020-12-02 Par sujet Laurent Franceschetti

Je pense que c’est une très bonne question ! Je suis preneur, moi-aussi.

Tout effort dans ce sens, me paraît bon.

L.

> Le 2 déc. 2020 à 14:06, Pascal Damien  a écrit :
> 
> Bonjour,
> 
> Je suis une pive et débutant Linux.
> 
> Donc si ma question est trop Basic, désolé.
> 
> On a téléchargé l'iso d'Unbuntu et sous Windows graver la clé USB avec Rufus.
> 
> Avec la touche option cela boot dessus.
> 
> Pour un des macs mini, on est arrivé à bouter sur un lecteur de DVD externe, 
> de bon vieux souvenir pour graver le DVD.
> 
> Il y a surement des solutions plus pros
> 
> Bonne journée
> 
> 
> Le 02.12.2020 à 12:00, Laurent Franceschetti a écrit :
>> Soit dit en passant, j’ai un très vieux mac mini (15 ans) auquel je suis 
>> affectionné, sur lequel j’aimerais installer une distro Linux. J’ai essayé 
>> toute sortes d’incantations, mais je n’ai pas réussi à le convaincre à 
>> booter pour installer depuis un CD ou un USB. :-(
>> 
>> Si quelqu’un pouvait me donner quelques tuyaux, je serais partant…
>> 
>> Bien à vous,
>> Laurent
>> 

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Linux sur des iMac légal ?

2020-12-02 Par sujet Laurent Franceschetti


Soit dit en passant, j’ai un très vieux mac mini (15 ans) auquel je suis 
affectionné, sur lequel j’aimerais installer une distro Linux. J’ai essayé 
toute sortes d’incantations, mais je n’ai pas réussi à le convaincre à booter 
pour installer depuis un CD ou un USB. :-(

Si quelqu’un pouvait me donner quelques tuyaux, je serais partant…

Bien à vous,
Laurent


> Le 2 déc. 2020 à 11:39, Frédéric Schütz  a écrit :
> 
> On 2/12/20 11:26 am, Pascal Damien wrote:
> 
>> Les iMac ayant souvent 8 ans on pensaient mettre Linux dessus. Je ne
>> sais pas encore la distribution que nous utiliserons, peut-être MX Linux
>> et les donner à des associations, notamment pour des jeunes qui à Genève
>> n'ont pas accès au numérique.
>> 
>> Mais c'est légal selon vous de mettre Linux sur un Mac ?
> 
> Absolument sans aucun doute, oui.
> 
> S'il devait y avoir un problème, ce serait plutôt du côté technique
> (matériel verrouillé ou ce genre de choses).
> 
> Frédéric
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Aggrégation libre des nouvelles - à la rescousse ?

2020-11-28 Par sujet Laurent Franceschetti

Bonjour,

Je me rends compte qu’il y a un vrai risque — même pour nous — à nous faire «
capturer » par les flux d’information de ce que j’appelle les RSM (réseaux
sociaux de multinationales) come FB, LinkedIn, mais aussi Google, etc.). Certes
les médias de masse traditions sont moribonds: la presse traditionnelle est
quasiment kaputt, et la télé est progressivement remplacée par le streaming.

Mais le nouveau danger est désormais de devenir prisonnier de la « bulle » de
l’information définie par des algoritmes de sociomatrices
<https://fr.wikipedia.org/wiki/Sociogramme> (ou sociogrammes).

Le premier souci du secouriste devrait être d'assurer sa propre survie, avant
celle des autres (sinon ça ne servira à rien, puisqu'’il s’ajoute à la
statistique des accidents).

La question est pour une personne qui renonce aux flux des RSM comment se
maintenir, pratiquement dès le jour zéro, bien informé ?

La première solution qui me vient à l’esprit (et qui fonctionne, d’ailleurs),
c’est de se monter un petit aggrégateur de news (client) avec des flux RSS. Il
y a une raison à cela: le système de l’information (y-compris pour les médias)
repose historiquement sur le communiqué de presse (de gouvernements,
d’entreprises, d’associations, etc.). L’aggrégateur RSS est la « salle des
télex », des rédactions où arrivaient les dépêches. Une agence d’information
(comme AFP, etc.), n’est rien d'autre qu’un aggrégateur. Donc avec le RSS, on
se recrée, pour soi, l’équivalent d’une agence de presse. Ca paraît donc tout à
fait dans l’esprit « do-it-yourself » du hacker.

Par contre, ce qui m’inquiète, c’est qu’il y a eu récemment une perte d’intérêt
pour le RSS. Peut-être que vous pourriez m’aider en répondant à ces questions:

Combien d’entre nous utilisent activement le RSS en ce moment ? Si oui ou non,
pourquoi ?
Quels sont les faiblesses du système ? (manque de standardisation, résultats
aléatoires en pratique, etc.?)
Est-ce que les Google, FB et autres n’auraient pas milité activement pour faire
mourir ce standard, perçu comme "concurrent »?
Comment ce standard devrait-il évoluer ? Quelles mesures devraient êtres prises
?
Y-a-t-il de meilleures solutions possibles (libres) que le RSS ?
D’autres questions ?

Bonne journée,
Laurent

Laurent Franceschetti
(Geneva, Switzerland)
laur...@franceschetti.net <mailto:laur...@franceschetti.net>

__
No one shall be subjected to arbitrary interference with his privacy, family,
home or correspondence, nor to attacks upon his honour and reputation. Everyone
has the right to the protection of the law against such interference or attacks
(Art 12 Universal Declaration of Human Rights).

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

C’est un domaine que je connais moins, mais il me paraît effectivement 
important de conserver des compétences dans ce domaine (donc de savoir 
installer des parcs de machines « bare metal », avec des méthodes 
industrielles). Pour ma part, je suis assez curieux à propos de Ansible : je 
trouve que l’idée est originale et assez puissante. 

Et ce, toujours dans une perspective d’une alternative aux GAFAM. À la fin des 
années 1970, on a été préoccupé par le monopole d’IBM sur le matériel; ensuite, 
dans les années 1990, de Microsoft sur le logiciel; aujourd’hui des GAFAM sur 
le cloud. On dirait que la menace du monopople persiste, mais qu’elle change 
perpétuellement de forme.  Et la réponse a toujours été la même: les standards 
ouverts, l’esprit de corps de la communauté, et… l’âme de chaque 
non-conformiste qui refuse de laisser les choses aller au diable.

Donc l’enjeu du présent ne serait plus uniquement le FLOSS 
(Free-Libre-and-Open-Source-Software) mais le « FLOSC » (…-Cloud) ?

Est-ce que ma compréhension sur les buts du « libre », et sur l’évolution de 
notre mission. correspond à la vôtre ?



> Le 25 nov. 2020 à 22:14, Arnaud  a écrit :
> 
> Le 25.11.20 à 22:03, Laurent Franceschetti a écrit :
>> Ah oui, ça c’est le top ! Après c’est une question de 
>> coût(effort)/opportunité… Car des services partagés sur des centres 
>> d’hébergement sont vraiment très bon marché.. Mais ça serait la solution de 
>> repli ultime...
> 
> De nos jours, d'après ce que j'ai vu, et par expérience, les coîts ne sont 
> pas si élevés que ça.
> Mais c'est clair que comparé à un hébergement chez un fournisseur, il faut 
> comparer (redondance électrique, connexion, etc.)
> 
> Mais je me forme à l'AI, le cloud computing, et à la gestion de machines par 
> k0s/k3s/k8s, openshift/openstack, ansible et autres,
> alors cette installation a plusieurs raisons d'exister.
> 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

Ah oui, ça c’est le top ! Après c’est une question de coût(effort)/opportunité… 
Car des services partagés sur des centres d’hébergement sont vraiment très bon 
marché.. Mais ça serait la solution de repli ultime...



> Le 25 nov. 2020 à 21:57, Arnaud  a écrit :
> 
> Le 25.11.20 à 21:36, Laurent Franceschetti a écrit :
>> Perso, je pense qu'une voie à suivre serait «  l’auto-hébergement facilité » 
>> (c’est-à-dire que des hébergeurs fournissent une installation « clé en main 
>> » d’applications Open Source). Je connais un peu mieux Infomaniak, et je 
>> sais qu’ils ont fait des efforts dans ce sens (en tout cas avec les applis 
>> PHP comme WordPress et nextcloud). Je pense aussi qu’il y a d’autres 
>> hébergeurs qui font ça ?
> 
> Personnellement, je suis en train de créer mon propre cloud personnel, 
> auto-hébergé chez moi :)
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

> 
> Le 25 nov. 2020 à 21:01, Daniel Cordey  a écrit :

> Bonne initiative ! J'essaie aussi de passer à Signal, mais plein de mes 
> contacts ne suivent pas vraiment, hélas.
> 


Pour ma part, j’ai eu pas mal de succès à faire migrer des non-informaticiens 
autour de moi sur Signal. Notamment des gens qui se sentaient mal à l’aise avec 
Facebook ou ce genre d’outils et qui sont sensibles aux arguments sur la 
sécurité. D’autant plus que l’appli s’est bien améliorée.

J’ai vu que cela payait d’y aller « franco » et d’expliquer les vraies raisons 
autour de soi, tout en restant compréhensible. Ceci est facilité, en ce moment, 
c’est que la confiance dans les GAFAM n’est pas très élevée en ce moment dans 
l’opinion publique. Surtout avec les discussions autour de la censure, qui ont 
été particulièrement vives dernièrement. Les gens ont besoin de changement, 
donc ça pourrait être bon pour le « libre et open source »… pour autant qu’on 
étende la définition , pour qu’elle inclue aussi les services en ligne. 

Perso, je pense qu'une voie à suivre serait «  l’auto-hébergement facilité » 
(c’est-à-dire que des hébergeurs fournissent une installation « clé en main » 
d’applications Open Source). Je connais un peu mieux Infomaniak, et je sais 
qu’ils ont fait des efforts dans ce sens (en tout cas avec les applis PHP comme 
WordPress et nextcloud). Je pense aussi qu’il y a d’autres hébergeurs qui font 
ça ?

Pour ceux qui se souviennent des distro Linux au milieu des années 1990, 
c’était assez sportif… maintenant c’est quasiment devenu du « presse-bouton ». 
Est-ce qu’on va arriver à ce genre de services, mais pour des applications « 
serveur » clé en main, auto-hébergées, pour des chats, des blogs, des wikis ? 
Des sortes de "distros" dans le cloud pour petits entreprises, associations ou 
particuliers ? 
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Reseaux sociaux et RGPD/GDPR - quelle demarche efficace ?

Sur le principe, il faudrait leur demander avant de… te désincrire :-) Donc 
ouvre un ticket auprès de leur service client et tu leurs demandes. La même 
RGPD, sauf erreur, exige qu’ils soient capables de te livrer ta propre 
propriété intellectuelle.

Voici un site qui explique les démarches:
https://demarchesadministratives.fr/demarches/comment-recuperer-ses-donnees-personnelles-collectees-par-les-reseaux-sociaux
 



Et bravo pour l’initiative de se désincrire de réseaux sociaux « GAFAM ». Cela 
fait un moment que je me disais que ce serait sérieusement le moment de se 
désintoxiquer des médias de masse (télé, radio). Jusqu’à ce que je me rende 
bien compte que ces réseaux sociaux constituaient une autre forme de défonce et 
qu’après on est trop à leur merci (ce qu’on a le droit de voir ou ne pas voir, 
le droit de dire ou ne pas dire…). 

Du coup, c’est la cure de désintoxication !

L’idée, c’est de faire la même démarche qu’on a faite pour le Logiciel Libre, 
mais face aux gros réseaux sociaux: tout remplacer par de l’auto-géré (Open 
Source), auto-hébergé, ou quelque chose qui s’en rapproche. 

Communications: Whatsapp à la poubelle, remplacé par Signal 
 (et pour la boîte c’est du rocket.chat 
 auto-hébergé, c’est du tonnerre).  Mon réseau de 
contacts est en train de passer progressivement à Signal.
J’ai monté mon propre blog cousu main en static html (avec Mkdocs-Material 
 mkdocs-macros 
); avec un « manifeste 
» pour expliquer la démarche 
).
Je redécouvre les joies du RSS/atom… Pour l’expérience, je trouve Raven 
(desktop app, Open Source) assez moyen et limité; par contre l’extension 
Feedbro Reader  
de Firefox est respectable (la présentation fait encore un peu « années 2000 », 
mais ça s’améliore si on passe en mode « dark »).

L’idée n’est pas forcément de convertir tout le monde (pas plus qu’on a 
converti tout le monde à Linux ou à l’Open Source); mais de se reconquérir 
notre propre espace de liberté. Et c’est le bon moment, car j’ai senti, dans 
les dernières semaines, un gros ras-le-bol de pas mal de contacts 
non-informaticiens, qui veulent eux aussi du changement.

Très intéressé par toutes les idées, démarches qui vont dans ce sens.

Bonne soirée,
Laurent




> Le 25 nov. 2020 à 17:18, Frédéric Dumas  a écrit :
> 
> 
> Avant de cliquer sur « supprimer mon profil » sur un réseau social, je 
> voulais demander conseil ici, même si le sujet n’est pas strictement logiciel.
> 
> Le marketing « digital » est tellement habile à nous empapaouter, qu’on finit 
> par se méfier même des messages les moins ambigus. Est-ce que le message 
> suivant :
> 
>> veuillez noter que la suppression des données de votre profil est définitive 
>> et irréversible.
> 
> veut dire qu’ils vont effacer mes données personnelles de leurs bases, ou 
> veut dire qu’ils vont supprimer mes données personnelles de l’affichage sur 
> leur site web (les conservant en réalité sans m’y donner accès, pour les 
> seuls besoin du data mining)?
> 
> Celui qui clique sur « supprimer mon profil » ne fait-il pas en fait une 
> fausse manoeuvre, ne lui faudrait-il pas mieux demander la suppression des 
> données le concernant au titre de la RGPD ?
> 
> Le réseau dont il s’agit ici est Xing.
> 
> Comment faites-vous personnellement ?
> 
> Merci.
> 
> 
> PS: on évitera s’il vous plait les réponses telles que: « il suffisait 
> simplement de ne pas t’inscrire... ».
> 
> --
> Frédéric Dumas
> f.du...@ellis.siteparc.fr
> 
> 
> 
> 
> 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Last phase of the desktop wars?

2020-10-04 Par sujet Laurent Franceschetti

En effet! J’ai réagi sur LinkedIn 
.

Je le reporte ici:

"Ahhh... lots of people made a hullaballoo about what Eric S. Raymond said 
about the Linux kernel being (plausibly) the future of Windows. In other words: 
Microsoft might ditch the Windows kernel.

First: I will vent off my frustration. PLEASE READ THE F...ING ORIGINAL TEXT, 
NOT SOME PARAPHRASE BY A JOURNALIST !

Now that this is out of the way, here is my two-bit about it.

Yes, of course. After all, Apple did the same thing with their own MacIntosh 
operating system, already two decades ago. The only difference, is that Steve 
Jobs had used the BSD flavor of Unix.

Basically, your Mac operating system, is a Unix system, and it's really 
convenient for everybody. That allows Apple to focus on what they are really 
interested in: the bottom part (the drivers and such they need to talk to the 
micropressors and peripherals); and the top part (the graphical user 
environment, i.e. the "Mac experience").

Microsoft developed their current kernel ("Windows New Technology", aka Windows 
NT) back in the early 1990s. Clearly that system has run its course. In the 
grand scheme of things, there is little point in maintaining it, so that 
Microsoft would remain the last of the Mohicans in a Unix world.

Nothing of the above relies on Microsoft's official announcements. But it does 
make sense. »



[Pardonnez mon éclat: j’en avais un peu assez de voir des gens citer des 
journaux au lieu de l’original. Les hyper-liens ont été inventés durant les 
années 1980 pour accéder aux documents originaux, pour ne plus avoir à passer 
par des journaux. On est en 2020, et l’habitude n’a toujours pas été prise, 
dans le grand public, d’aller à la source...]



> Le 4 oct. 2020 à 09:51, Daniel Cordey  a écrit :
> 
> Ça vient gentiment... :-)
> 
> http://esr.ibiblio.org/?p=8764
> 
> dc
> 
> 
> 
> 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Équivalent de Time Machine

2020-10-02 Par sujet Laurent Franceschetti

Syncthing est un très beau projet. C’est une alternative aux solutions de type 
« Dropbox » (propriétaire) et « Owncloud » ("self-hosting").
https://syncthing.net/ 

A vrai dire ce n’est pas tout à fait une solution de backup. Mais il peut 
certainement être inséré dans stratégie de DRP (Disaster Recovery Planning), 
comme tu sembles le faire? 

Notamment, quel avantage y a-t-il, à ton avis, à mettre les données dans des 
bases de données? 

> Le 1 oct. 2020 à 18:31, Daniel Cordey  a écrit :
> 
> 
> 
> 
> je ne suis pas (plus) fan de solutions basées sur des centaines/milliers de 
> fichier. Si ça permet de se rattraper en cas de problèmes, c'est quand même 
> vachement lourdingue à gérer. Aujourd'hui, les masses de données sont plus 
> importantes que lorsque l'on pouvait gérer ça avec des tars et des noms de 
> fichiers. Perso, j'ai complètement abandonné cette stratégie trop lourde dans 
> un environnement de cluster. J'ai tendance à plus penser à mettre mes données 
> dans des DBs et à utiliser des outils comme duplicity, seafile, syncthink, 
> etc.
> 
> 
> ull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Scan OCR et payement en ligne.

2020-08-11 Par sujet Laurent Franceschetti

Bonjour,

Tout d’abord je voulais dire « merci » à Félix, parce qu’il est important que 
les services bancaires soient aussi accessibles sur Linux (on a déjà eu 
l’occasion d’en parler…). Et des fois, la clé se trouve au niveau des drivers…

Pour le QR Bill, je suis en train de travailler sur un script (en Python) qui 
lit les images et les décode et les rend sous diverses formes (texte, json avec 
les champs, etc.). J’ai utilisé effectivement zbar, en combinaison avec opencv. 
Ca m’a fait transpirer, parce que je ne suis pas un spécialiste du scan 
d'image… c’est simple en théorie, mais le rendre fiable c’est autre chose! Mais 
maintenant il a réussi à interpéter un jpg pris avec un appareil photo de 
smartphone. 

Je me demandais si j’allais mettre sur github?

Le QR Bill contient beaucoup plus d’informations, notamment le numéro de 
facture et les coordonnées du fournisseur. Le scan a donc deux fonctions: une, 
qui est de saisir le paiement (comme aujourd’hui), et l’autre qui est 
d’alimenter le programme de compta! A votre connaissance, quelqu’un a pensé à 
cet aspect?

Bonne journée,
Laurent

> Le 11 août 2020 à 18:01, felix  a écrit :
> 
> Bon.
> 
> J'ai donc adapté mon script perso et geeky pour en faire un truc à lancer avec
> un racourci clavier:
> 
>  https://f-hauri.ch/vrac/scanocr-xdotool.sh.txt
>  https://f-hauri.ch/vrac/scanocr-xdotool.sh
> 
> Une fois lié à une touche clavier via préférences -> shortcut, il suffit
> de se mettre sur le site de banking, dans le formulaire pour saisir la ligne,
> positionner le bulletin de versement *A L'ENVERS* dans le scanner et appuyer
> sur la touche choisie.
> 
> Le script scan le ``bas'' (càd le haut, retourné) du bulletin,
> test les checksums (PZ10) et si ok, utilise xdotool pour taper la ligne
> dans le formulaire.
> 
> (Utilise scanimage, netpbm et xdotool)
> 
> Notez que le bulletin est retourné pour éviter au scanner de parcourir toute 
> la
> page (la plupart de scanners scannent du haut vers le bas).
> 
> Voilà, en espérant que cela profite à qqn (d'ici les QR généralisés).
> 
> NB: Pour les QR, le script sera à adapter avec zbar, mais ils risque d'être
> utile quand-même!
> 
> On Sat, Aug 08, 2020 at 05:57:36PM +0200, felix wrote:

 Comment faites-vous? Quelle solution pour copier-coller cette ligne:

  0>000+ 0>
  1234567890128>123456789012345678901234567+ 123456786>

> 
> -- 
> Félix Hauri  --  http://www.f-hauri.ch
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Nixos on ARM

2020-07-13 Par sujet Laurent Franceschetti

Top!

Pour l’éditeur, mon expérience m’enseigne que ce n’est pas vraiment 
significatif et je dirais d’utiliser ton IDE favori. Markdown est suffisamment 
clair pour être interprété mentalement, et les plugins de Visual Code ou Atom, 
ainsi qu’Emacs (même si je n’ai pas essayé ce dernier), devraient faire 
parfaitement l’affiare. Après, des goûts et des couleurs… :-)

La visualisation du résultat à l’écran sert surtout en « pré-compilation » pour 
un check visuel qu’on n’a pas négligé un détail important (très utile); 
autrement, ça ne sert pas à grand-chose. AMHA, le bon vieux mode caractère, 
avec colorisation de la syntaxe, c’est encore ce qu’il y a de mieux.

A+
Laurent


> Le 13 juil. 2020 à 11:55, Pirboazo  a écrit :
> 
> Bonjour,
> 
> 
> 
> Effectivement le thème material est excellent. On va l'utliser pour faire une 
> documentation technique de notre PPE (Chauffage, Electricité ...)
> 
> 
> 
> J'ai une question concernant Markdown , quel est a t on avis l'éditeur est le 
> plus proche de la syntaxe de la bibliotheque python ?
> 
> 
> 
> A+
> 
> Pierre
> 
> 

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Nixos on ARM

2020-06-25 Par sujet Laurent Franceschetti


Très heureux d’avoir contribué à acquérir quelqu’un à la cause de cet excellent 
outil!

> Le 25 juin 2020 à 19:28, Pirboazo  a écrit :
> Hello, J'ai quasi atteint mon objectif.
> 
> 
> 
> 80 % de mon site passer de MdWiki à MkDocs , me reste enore pas mal de 
> tunning comme on dit parfois.
> 
> Merci pour les retours.
> 

Tu es lancé! 

Pour ma part j’ai une nette préférence pour le thème material, qui est une 
vraie boîte à outils, avec de belles extensions (notes de bas de page, 
note/attention, etc.):
https://squidfunk.github.io/mkdocs-material/getting-started/ 



Dans le mkdocs.yml:

theme: 
  name: material
  language: en
  font: "Open Sans"

(tu peux mettre le font et la langue que tu veux).


Cordialement,
Laurent

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Nixos on ARM

2020-06-24 Par sujet Laurent Franceschetti

J’ai pour ma part une nette préférence pour mkdocs  
(base Python), qui est très riche et qui a créé de la traction. Maintenant que 
j’ai l’habitude, je suis en mesure de monter un site de documentation avec un 
look pro en quelques minutes… plus le temps de rédaction.

J’ai pour ma part écrit un plugin mkdocs-macros 
, qui me permet de 
retrouver des facilités d’un vrai wiki (macros, variables, etc.), que j’avais 
avec dokuwiki. 

Apparemment ce petit plugin a un succès d’estime — parmi mes « clients », j’ai 
par exemple Clickhouse  qui est un 
projet à 10.000 likes (mon petit plugin en est bien sûr très loin…). J’ai même 
Microsoft avec son projet mu  (pas d’idée 
précise de ce que c’est, mais c’est juste pour faire du name dropping...).

A+
Laurent

> Le 24 juin 2020 à 15:53, Pirboazo  a écrit :
> 
> Merci,
> 
> Le langage pour générer le site je n'ai pas d'apriori , par contre pour
> les pages je veux pouvoir intégrer soit du markdown soit de l'html.
> 
> Il y a bcp de solutions effectivement.;-(
> 
> A+
> 
> On 6/23/20 9:48 PM, Philippe Ney wrote:
>> Bonjour,
>> 
>>> PS : le site est fait avec MDwiki  , je
>>> souhaite le migrer , j'ai testé pelican :-\ je vais tester hugo ,
>>> auriez vous d'autre proposition ?
>> 
>> Tout dépend du langage que vous désirez utiliser. Vous devriez trouver
>> votre bonheur ici :
>> 
>> https://www.staticgen.com/
>> 
>> Bonne chance,
>> 
>> Philippe
>> ___
>> gull mailing list
>> gull@forum.linux-gull.ch
>> https://forum.linux-gull.ch/mailman/listinfo/gull
> 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] "Test public de sécurité" SwissCovid

2020-06-23 Par sujet Laurent Franceschetti

A ce propos, github me signale l’issue suivante ouverte sur le projet Android 
de DP-3T (qui fait référence à la mienne):
https://github.com/DP-3T/dp3t-sdk-android/issues/10 
<https://github.com/DP-3T/dp3t-sdk-android/issues/10>



> Le 22 juin 2020 à 18:35, Laurent Franceschetti  a 
> écrit :
> 
> 
> Le MELANI demande un Public Security Testing:
> 
> https://www.melani.admin.ch/melani/fr/home/public-security-test/scope_and_rules.html
> 
> La question qui me taraude, c’est qu’est-ce qu’ils veulent qu’on teste? À ma 
> connaissance,  on ne peut pas compiler l’application, on ne peut pas 
> répliquer le serveur, le code n’est pas commenté et il manque la 
> documentation pertinente.
> 
> Je ne pense pas que chez MELANI, ils sont méchants, mais plutôt qu’ils ont 
> très peu de familiarité avec le sujet de la sécurité informatique. 
> 
> Mais comme il n’y aura pas beaucoup de soumissions (puisque on ne peut rien 
> tester), ils seraient encore capables d’annoncer triomphalement que 
> l’application est déclarée secure puisque personne n’a trouvé de failles. 
> Quelqu’un aurait des suggestions sur ce qu’on devrait faire?
> 
> Cordialement,
> Laurent

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] "Test public de sécurité" SwissCovid

2020-06-23 Par sujet Laurent Franceschetti

Arnaud et Alexis,

Est-ce que vous êtes en train de répondre à la question?

Cordialement,
Laurent

> Le 23 juin 2020 à 12:35, Alexis Roussel  a écrit :
> 
> de ce que j'ai compris.
> 
> si on est malade, on poste un code en ligne.
> 
> si on est pas malade, on verifie régulierement qu'il n'y a pas de code
> qui nous correspond.
> 
> je pense qu'une connexion wifi suffit pour cela.
> 
> 
> On 23.06.20 12:31, Arnaud wrote:
>> Je ne la trouve pas si stupide :)
>> 
>> J'ai moi-même un smartphone où j'ai bloqué la connexion data autant sur 
>> l'abonnement prépayé que sur le téléphone,
>> que je mets en mode avion en permanence et qui ne me sert que pour écouter 
>> de la musique de fichiers locaux que je place dessus,
>> ayant des CAT B30 en 3G qui seront valable jusqu'en 2024 pour la téléphonie 
>> :)
>> 
>> J'ai mis une carte SIM dedans, mais je me rends compte qu'elle ne me sert à 
>> rien en fait ^^
>> Donc je suis aussi intéressé par la réponse.
>> 
>> Cordialement,
>> Arnaud
>> 

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] "Test public de sécurité" SwissCovid

2020-06-22 Par sujet Laurent Franceschetti


Le MELANI demande un Public Security Testing:

https://www.melani.admin.ch/melani/fr/home/public-security-test/scope_and_rules.html

La question qui me taraude, c’est qu’est-ce qu’ils veulent qu’on teste? À ma 
connaissance,  on ne peut pas compiler l’application, on ne peut pas répliquer 
le serveur, le code n’est pas commenté et il manque la documentation pertinente.

Je ne pense pas que chez MELANI, ils sont méchants, mais plutôt qu’ils ont très 
peu de familiarité avec le sujet de la sécurité informatique. 

Mais comme il n’y aura pas beaucoup de soumissions (puisque on ne peut rien 
tester), ils seraient encore capables d’annoncer triomphalement que 
l’application est déclarée secure puisque personne n’a trouvé de failles. 
Quelqu’un aurait des suggestions sur ce qu’on devrait faire?

Cordialement,
Laurent
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] SCOOP: Rapport censuré du LASEC sur SwissCovid

2020-06-17 Par sujet Laurent Franceschetti

Bonsoir,

J’ai fait une petite vidéo sur la question, qui est adressée plutôt à des 
compliance (du monde bancaire) ou des juristes. Mais je pense que, justement 
parce que ce n’est pas du point de vue de l'informaticien, cela pourrait être 
intéressant?

https://www.youtube.com/watch?v=BtYmI3NfCk8 
<https://www.youtube.com/watch?v=BtYmI3NfCk8>

Bonne journée,
Laurent


> Le 17 juin 2020 à 09:40, Philippe Moret  a écrit :
> 
> J'ai lu la discussion sur l'issue ça vole pas très très haut.
> La réponse de Melani ne donne pas vraiment satisfaction quant à la protection 
> des données:
> " *Effect on the privacy of the users*
> We believe that under normal circumstances, the privacy of the users does not 
> constitute an
> unacceptable higher risk when using the app. If a user has a smartphone with 
> Bluetooth ena-
> bled (e.g. for headphones), she accepts certain risks associated with this 
> technology. The
> same is true for the Swisscoovid App. One might argue that the overall attack 
> surface for the
> population rises because users are pushed into activating Bluetooth. While 
> this is true, we
> believe that many people already have Bluetooth enabled and that Bluetooth 
> based proximity
> tracing is still the better option than using actual geolocation information. 
> We do not see any
> other better technologies that could be made ready within the given 
> timeframes." 
> 
> En gros les citoyens sont déjà des inconscients, ça nous arrange bien ça sera 
> pas bien pire avec notre application...
> 
> 
> On Wed, Jun 17, 2020 at 9:28 AM Laurent Franceschetti 
> mailto:laur...@franceschetti.net>> wrote:
> Voici la réponse du chef de projet (extrait, j’ai omis ses arguments « ad 
> personam »):
> 
>> The LASEC report is part of the normal Public Security Test process. It has 
>> been read by the several national security agencies and an official answer 
>> has been provided by the Melany group : 
>> https://www.melani.admin.ch/melani/en/home/public-security-test/current_findings.html
>>  
>> <https://www.melani.admin.ch/melani/en/home/public-security-test/current_findings.html>
>> (…) If you find serious security holes, inform the community or the Federal 
>> Data Protection Officer (https://www.edoeb.admin.ch/edoeb/fr/home.html 
>> <https://www.edoeb.admin.ch/edoeb/fr/home.html>). The whole team would be 
>> grateful.
>> 
> N’est-ce pas une curieuse façon de répondre à une issue sur Github, pour un 
> projet qui se présente sous une licence MPL?
> 
> Cordialement,
> Laurent
> 
> 
> 
>> Le 16 juin 2020 à 17:57, Laurent Franceschetti > <mailto:laur...@franceschetti.net>> a écrit :
>> 
>> Merci, c’est fait!
>> https://github.com/DP-3T/documents/issues/325 
>> <https://github.com/DP-3T/documents/issues/325>
>> 
>> 
>> 
>> 
>>> Le 16 juin 2020 à 17:31, Alexis Roussel >> <mailto:ale...@roussel-zeter.eu>> a écrit :
>>> 
>>> Tu dois ajouter une issue ici: https://github.com/DP-3T/documents/issues 
>>> <https://github.com/DP-3T/documents/issues>
>>> avec le lien du document ( un lien fixe)
>>> 
>>> En demandant une réponse à ce document.
>>> 
>> 
>> ___
>> gull mailing list
>> gull@forum.linux-gull.ch <mailto:gull@forum.linux-gull.ch>
>> https://forum.linux-gull.ch/mailman/listinfo/gull 
>> <https://forum.linux-gull.ch/mailman/listinfo/gull>
> ___
> gull mailing list
> gull@forum.linux-gull.ch <mailto:gull@forum.linux-gull.ch>
> https://forum.linux-gull.ch/mailman/listinfo/gull 
> <https://forum.linux-gull.ch/mailman/listinfo/gull>___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] SCOOP: Rapport censuré du LASEC sur SwissCovid

2020-06-17 Par sujet Laurent Franceschetti

Voici la réponse du chef de projet (extrait, j’ai omis ses arguments « ad 
personam »):

> The LASEC report is part of the normal Public Security Test process. It has 
> been read by the several national security agencies and an official answer 
> has been provided by the Melany group : 
> https://www.melani.admin.ch/melani/en/home/public-security-test/current_findings.html
>  
> <https://www.melani.admin.ch/melani/en/home/public-security-test/current_findings.html>
> (…) If you find serious security holes, inform the community or the Federal 
> Data Protection Officer (https://www.edoeb.admin.ch/edoeb/fr/home.html 
> <https://www.edoeb.admin.ch/edoeb/fr/home.html>). The whole team would be 
> grateful.
> 
N’est-ce pas une curieuse façon de répondre à une issue sur Github, pour un 
projet qui se présente sous une licence MPL?

Cordialement,
Laurent



> Le 16 juin 2020 à 17:57, Laurent Franceschetti  a 
> écrit :
> 
> Merci, c’est fait!
> https://github.com/DP-3T/documents/issues/325 
> <https://github.com/DP-3T/documents/issues/325>
> 
> 
> 
> 
>> Le 16 juin 2020 à 17:31, Alexis Roussel > <mailto:ale...@roussel-zeter.eu>> a écrit :
>> 
>> Tu dois ajouter une issue ici: https://github.com/DP-3T/documents/issues 
>> <https://github.com/DP-3T/documents/issues>
>> avec le lien du document ( un lien fixe)
>> 
>> En demandant une réponse à ce document.
>> 
> 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] SCOOP: Rapport censuré du LASEC sur SwissCovid

Merci, c’est fait!
https://github.com/DP-3T/documents/issues/325 





> Le 16 juin 2020 à 17:31, Alexis Roussel  a écrit :
> 
> Tu dois ajouter une issue ici: https://github.com/DP-3T/documents/issues 
> 
> avec le lien du document ( un lien fixe)
> 
> En demandant une réponse à ce document.
> 

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] SCOOP: Rapport censuré du LASEC sur SwissCovid

Bonjour,

J’ai enfin reçu le rapport du LASEC que la direction de l’EPFL avec 
"malencontreusement » censuré lors du débat au Parlement de la loi urgent sur 
les épidémies (20.040).

https://www.swisstransfer.com/d/6c06f896-1d1e-48b4-99ff-cef9debaff7a

On m’a assuré que l’embargo avait été levé aujourd'hui. C’est tout de même 
formidable que l’Ecole ait attendu que les débats soient clos au National et au 
Conseil des Etats pour le publier. Néanmois la loi n’a pas encore été votée 
(vote final le 19).

Donc si on veut faire du ramdam avec les députés au parlement 
<https://www.parlament.ch/Poly/Adressen_RM/raete.pdf>, ce n’est pas trop tard. 
A faire circuler sans modération. C’est ça ou se taper un référendum...


Cordialement,
Laurent



Laurent Franceschetti
(Geneva, Switzerland)
laur...@franceschetti.net <mailto:laur...@franceschetti.net>

__
No one shall be subjected to arbitrary interference with his privacy, family, 
home or correspondence, nor to attacks upon his honour and reputation. Everyone 
has the right to the protection of the law against such interference or attacks 
(Art 12 Universal Declaration of Human Rights).



___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Données sensibles en entreprise



> Le 16 juin 2020 à 14:09, Daniel Cordey  a écrit :
> 
> 
> 
>> Je n'ai pas l'impression qu'il faille être paranoïaque:
> 
> Détrompez-vous ! L'accès aux données est devenu un véritable business qui 
> rapporte de l'argent. C'est l'un des principales activités des pirates 
> aujourd'hui; afin de pouvoir les revendre sur internet (# de carte de crédit 
> par exemple). Il faut justement se montrer très stricte, mais pas besoin de 
> se déguiser en Ninja pour se rendre au bureau non plus.
> 

Pour ceux qui veulent un produit super sûr (niveau banque, Suisse, etc.), 
j’utilise SecureSafe depuis plusieurs années.

https://www.securesafe.com/fr/s%C3%A9curit%C3%A9/ 



Disclaimer, ce n’est pas open source; et j’ai travaillé avec eux aussi au 
niveau commercial. Mais c’est une pour bonne raison, car c’est un produit 
remarquable.



___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Données sensibles en entreprise

Bonjour,

Comme solution toute faite, qui fonctionne plutôt bien, il y a NextCloud (qui a 
d’ailleurs été présentée récemment par un membre du Gull) qui fonctionne sur 
PHP.

Je viens de l’installer pour une société (Infomaniak a d’ailleurs une procédure 
automatisée). Cela marche très bien, c’est fiable.

Nextcloud fournit aussi le stockage côté serveur: 
https://nextcloud.com/blog/encryption-in-nextcloud/ 


Pour le moment, je n’ai que du bien à en dire!

Cordialement,
Laurent




> Le 16 juin 2020 à 11:59, Grégoire Métral  a écrit :
> 
> Bonjour la liste,
> 
> J'ai une demande de ma hiérarchie pour mettre en place un "coffre-fort
> numérique" afin d'y stocker des données sensibles (mots de passe,
> données de carte de crédit ou autre). Après avoir fait un tour sur le
> web, je me rends compte que les solutions proposées sont très diverses,
> et j'ai de la peine à voir ce qui me conviendrait le mieux. Je me disais
> que certaines personnes de cette liste avaient probablement des
> expériences à partager.
> 
> Les données devront être visibles par plusieurs personnes (direction,
> administration). Nous avons à disposition des serveurs GNU/Linux (que
> nous pouvons configurer à notre goût), et les clients qui y auront accès
> sont variés (GNU/Linux, Windows et Mac). Je n'ai pas l'impression qu'il
> faille être paranoïaque: un système crypté et des mots de passe pour y
> accéder devraient faire l'affaire.
> 
> J'ai l'expérience de encFS, qui me convient bien, mais la version 1.8
> semble avoir encore des vulnérabilités. Est-ce que vous recommanderiez
> une solution de ce type? Ou un cryptage au niveau fichier? Faire
> attention plutôt au contrôle d'accès?
> 
> Merci d'avance pour vos retours!
> Greg
> 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Loi urgente sur les épidémies -- Rétention d'information de l'EPFL?

2020-06-11 Par sujet Laurent Franceschetti

Marc,

pour les réponses.
> 
> 
>> Bonjour,
>> 
>> Vous avez raison je pars du principe qu’un logiciel développé pour l’État 
>> est développé pour la communauté donc il devrait être libre par définition 
>> et le code source devrait être accessible
>> 
>> Qu’en est-il vraiment est-ce qu’on a accès au code source de Suisse Covid ou 
>> non ?

La réponse est oui pour la partie Suisse. Par contre c’est en fait une 
surcouche de l’API Google ou Android: qui est propriétaire et en principe non 
accessible.

Du coup, dans ma compréhension, on ne peut pas compiler.

D’autre part, on n’a pas les sources de l’appli serveur?


>> 
>> Une expertise indépendante est-elle possible ?

En principe l’expertise existe: c’est celle du LASEC. C’est vrai qu’elle vient 
de l’EPFL, mais elle a le mérite d’avoir été faite par une autre équipe, en 
contradictoire (et elle n’aurait pas été favorable).

D’après ce que j’ai compris, de toute façon ils n’ont pas pu vérifier grand 
chose, puisqu’ils n’avaient pas tous les sources. D’autre part, il faudrait 
vérifier si la doc publiée est pertinente.

Et à première vue, le code n’est quasiment pas commenté.

Amitiés,
Laurent

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Guichet spécial coronavirus: l'application SwissCovid, On en parle

2020-06-11 Par sujet Laurent Franceschetti

Peut-être qu’il ne faudrait plus parler de « l’application SwissCovid », mais 
de « l’affaire SwissCovid ». 

Et dans le Temps, le torchon brûle: 
https://www.letemps.ch/economie/swisscovid-feu-critiques-quatre-questions-comprendre

Il faut savoir que c’est un peu le « meltdown » au Conseil national à Berne, 
avec cette histoire du rapport du LASEC que l’EPFL avait gardé dans un tiroir. 
L’article est un effort pour l’éteindre, mais connaissant les journalistes, ils 
ont mis de l’huile sur le feu...


> Le 11 juin 2020 à 11:16, Miçhael Parchet  a écrit :
> 
> https://www.rts.ch/play/radio/redirect/detail/11357589
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Loi urgente sur les épidémies -- Rétention d'information de l'EPFL?

2020-06-09 Par sujet Laurent Franceschetti

En effet. Au passage, voici un article du prof. Serge Vaudenay (Directeur du 
LASEC, EPFL) du 6 mai.

https://eprint.iacr.org/2020/531







> Le 10 juin 2020 à 02:22, Marc Mongenet  a écrit :
> 
> Je n'ai malheureusement pas accès à l'article.
> Mais je trouve cela très bizarre. Il existe un GitHub depuis des
> semaines, donc les questions et analyses devaient y être postées et
> discutées. Si on a empêché les gens de le faire, ou qu'ils n'ont pas
> voulu le faire, alors c'est effectivement louche, et à l'opposé de
> principes de développement honnêtes et ouverts.
> Le Logiciel libre, c'est la liberté de créer et partager des
> logiciels. Et si l'on n'est pas content de ce qui existe, on reprend
> le code intéressant, on remplace le reste, et on fait un nouveau
> logiciel. Il y a d'ailleurs un vrai problème à ce niveau du fait que
> Google limite l'offre à un seul logiciel par pays. Sans compter le
> plus gros problème qui est que le Logiciel libre a un impact
> anecdotique sur mobile (noyau Linux enterré sous les couches
> d'Android, app stores, etc.).
> 
> Marc Mongenet
> 
___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

[gull] Loi urgente sur les épidémies -- Rétention d'information de l'EPFL?

2020-06-09 Par sujet Laurent Franceschetti

Bonjour,

J’ai failli tomber de ma chaise aujourd’hui: heidi.news a publié aujourd’hui
l’information que la Direction du Poly de Lausanne avec gardé dans un tiroir un
rapport très critique du Laboratoire de Sécurité et de Cryptographie (LASEC).
Et ce, alors que la loi sur Swisscovid est un discussion au parlement.

https://www.heidi.news/sante/une-analyse-de-l-epfl-met-en-garde-contre-les-failles-de-l-application-de-contact-tracing-swisscovid

Dit simplement, la direction de l’EPFL aurait fait de la rétention
d’information en interdisant la publication de ce rapport au Parlement et au
public. Si c’est vrai, ça risque de faire des histoires. En tout cas l’EPFL n’a
pas démenti et donc ce rapport du LASEC existe quasiment certainement. Et puis
ça inquiétant grave si on n’avait pas demandé son avis à ce labo, je pense?

Pourquoi ce que cela nous concerne? Parce que ce projet a bafoué les principes
du logiciel libre. Bien entendu cela n’en était pas, parce que vu qu’il
s’appuie sur des API propriétaires de Google et Android, on peut toujours
courir pour visualiser le code et le compiler sur nos machines!

On dirait que la Direction de l’EPFL, comme Faust, a pactisé avec Apple-Google
pour vendre sa solution au Parlement et faire un coup d’auto-pub. Tout cela en
se faisant passer pour un ami du logiciel libre.

Donc s’il y a des bonnes volontés, ce serait bien d’avoir :

Détails sur ce rapport du LASEC, et pourquoi la Direction l’a gardé dans un
tiroir?
Si vous avez un contact avec votre Conseiller(e) national(e) ou aux Etats,
écrivez leur pour demander de faire pression sur la Direction de l’EPFL pour la
publication immédiate de ce rapport

Voilà, donc pardonnezmoi. Cela fait des années que je suis membre de cette
liste et je n’ai pas l’habitude de monter au crénau comme ça. Mais là il se
pourrait qu’on ait été touchés au coeur de nos valeurs. On est en droit de
demander des comptes.

Bien à vous,

Laurent Franceschetti
(Geneva, Switzerland)
laur...@franceschetti.net <mailto:laur...@franceschetti.net>

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Stockage facile d'archives mail, quel MDA IMAP choisir ?

2020-06-08 Par sujet Laurent Franceschetti

Merci de vos appréciations. Alors j’ai bien fait de leur faire confiance.

Je dois dire que leur service est très bon, de même que le support. 

J’ai noté un peu de flottement au niveau du support pendant la crise de 
Coronavirus — juste un peu léger — mais comment leur en vouloir? Ils avaient 
sans doute des choses plus importantes à faire que de s’occuper de mes 
interrogations existentielles avec leur dyndns :-)


> Le 8 juin 2020 à 19:27, Daniel Cordey  a écrit :
> 
> 
> 
> On 08.06.20 18:31, Rémi Voirin wrote:
> 
>> Le rapport qualité/prix est bon, et jusqu'à mon départ fin 2017, il y
>> avait un vrai respect des données des clients. Je ne doute pas sur le
>> fait que cela ait perduré.
> 
> Oui, Infomaniak a toujours bonne réputation en Romandie. Surtout, en plus de 
> 20 ans leur nom n'a jamais été cité du côté sombre des forces du mal (revente 
> de données, etc.). En plus, je n'ai jamais entendu de critiques au niveau 
> fiabilité et disponibilité.
> 
>> J'ai refait le tour du marché pour mes propres besoins récemment : où
>> poser les MX pour lags.is, et finalement en Suisse - romande en
>> particulier - il n'y a pas tant de solutions que ça.
> 
> On peut héberger chez sois mais ce n'est pas évident d'assurer du non-stop, 
> surtout lorsque l'on est en vacances. On peut héberger son hardware chez un 
> fournisseur, mais au final ça représente quand même un certain coût. Car il 
> faut louer au minimum un demi-rack + bande passante + etc. Ou alors, on prend 
> un serveur virtuel que l'on gère aussi soi-même. Dans tous les cas, comme 
> vous l'avez dit plus tôt, il faut gérer le DNS et les MX, SPF, DMARC, etc. 
> Plus les antivirus (clamav étant une bonne solution). Mais il faut aussi 
> fournir un outil d'enregistrement des junks et là il faut un peu bricoler.
> 
> Tout ça peut-être fun, mais ça va si on a le temps !
> 
> Bonne soirée.
> 
> dc
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Stockage facile d'archives mail, quel MDA IMAP choisir ?

2020-06-08 Par sujet Laurent Franceschetti

Bonjour Rémi,

C’est bien ce que j’avais pensé… Du coup, à moins de vouloir passer beaucoup de 
temps, il veut mieux outsourcer à l’Infomaniak de service (ou votre préféré…)?

Cordialement,
Laurent




> Le 8 juin 2020 à 15:01, Rémi Voirin  a écrit :
> 
> Bonjour Laurent,
> 
> 
> Pour avoir travaillé dans le milieu, l'auto-hébergement est possible
> mais il faut beaucoup veiller.
> 
> Les gros fournisseurs (Gmail, Hotmail, ...) font loi et les contraintes
> anti-spam sont très rigoureuses. DKIM, SPF, DMARC, il faut mettre les
> bons champs dans les DNS pour se valider correctement. Si le range IP
> que tu utilises pour les SMTP s'avère être pollué un jour par des
> spammeurs, il faudra déployer des efforts pour se faire "délister" en de
> nombreux endroits.
> 
> En parallèle il faut gérer un anti-spam et les techniques toujours plus
> sournoises pour faire passer toutes sortes de mails au mieux inutiles,
> au pire nuisibles.
> 
> 
> Bon après-midi,
> 
> Rémi
> 

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Stockage facile d'archives mail, quel MDA IMAP choisir ?

2020-06-08 Par sujet Laurent Franceschetti


Merci à vous deux.

J’aimerais vous poser une question intéressante à ce sujet, à laquelle j’avoue 
n’avoir pas de réponse. 

Le serveur de messagerie d’une entreprise, est-ce que:

1. il vaut mieux le déléguer à une société externe (c’est de la « commodity », 
pour une somme très faible par mois pour toute l’entreprise)? 
2. Ou y a-t-il de bonnes raisons pour s’auto-héberger?

Depuis 2 décennies, pour moi 1 était un « no-brainer », pourvu que 
l’hébergement soit rigoureusement en Suisse.

Maintenant, j’aimerais me reposer la question.

Bien à vous,
Laurent



> Le 8 juin 2020 à 13:31, Philippe Ney  a écrit :
> 
> Bonjour,
> 
> Pour ma part je prendrais Dovecot, Cyrus ou Courier. Dans cet ordre.
> Mais si vous cherchez un système d'archivage de mails, vous pouvez regarder 
> Piler (http://www.mailpiler.org/).
> 
> Meilleures salutations,
> 
> Philippe
> 

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Projet EPFL traçage

2020-06-04 Par sujet Laurent Franceschetti

Marc, 

Je suis d’accord avec tout ce que tu dis. Je veux dire: c’est factuel :-) C’est 
tout à fait vrai qu'il y a un sous-site de documentation sur github et ils ont 
fait un effort. Et comme tu dis très justement « le travail de l’EPFL semble 
s’arrêter à… » .

Le problème c’est justement ça: quand on a une compétence technique — comme 
eux, comme chacun de nous — le fait de dire « je ne fais qu’obéir aux ordres et 
le reste n’est pas mon affaire », ça pose problème d’éthique.

Quelques pistes de réflexion sur le sujet:

En dehors d’un informaticien qui a pratiqué github, QUI serait capable 
d’accéder à l’entrepôt de DP-3T et de trouver quelque chose? 
À supposer qu’un juriste trouve l’entrepôt, est-ce qu’il va comprendre quelque 
chose? Et sans les juristes, on va débattre avec qui?
Pourquoi je me décarcasse à faire un petit site sur readthedocs pour mon plugin 
de mkdocs; mais l’EPFL n’a pas le temps de faire un petit site pour décrire 
comment installer application IOS en cours de développement, qui risque d’être 
utilisé par des centaines de milliers de personne
Pourquoi un ingénieur EPFL est-il moins bien placé qu’un autre pour parler d’un 
problème de société?

Ce que cette affaire SwissCovid révèle, c’est une balkanisation de la société. 
Il n’y a aucun discours public sensé possible, parce que l’ingénieur ne parle 
que de ci, le juriste ne parle que de ça, le politicien ne pale, etc.

Chacun de nous est tellement formatés à ne regarder que dans notre assiette, 
qu’on en oublie de regarder autour de nous et de voir ce qu’il y a d’illogique 
dans tout ça.

Ce que tu me dis de la gesticulation à la française, je le prends pour moi… 
c’est vrai, je l’ai importé de chez eux. Mais on le fait aussi en Suisse: quand 
moi je faisais l’armée (ce que je n’aimais pas trop), le sergent-major ne 
réveillait pas la caserne avec une attitude « euh oui, le principe c’est qu’il 
faudrait se réveiller, chacun est libre, il y a tous les avis… ». Comme le 
temps manquait jusqu’à l'appel, le sergent-major gueulait: DIANE DEBOUT!

Comme je n’avais plus le de temps pour faire ce que je préfère (de la 
philosophie) j’ai poussé une grosse bouêlée. Et là il y a plein de gens qui 
sont tombés de leur lit, en me maudissant. Mais ça va leur passer avec un bon 
café :-) 

Et quand les gens seront bien réveillés, et qu’ils auront fini de grommeler 
parce qu’ils voulaient rester au lit, on aura les bases pour une bonne 
dicussion. :-)

Bonne journée,
Laurent


> Le 5 juin 2020 à 01:57, Marc Mongenet  a écrit :
> 
> Bonsoir,
> 
> J'aurais dit que le site de documentation est
> https://github.com/DP-3T/documents. Que cherchais-tu comme
> documentation? En postant dans https://github.com/DP-3T/dp3t-sdk-ios/,
> la demande concerne le SDK iOS de DP-3T (qui est encore en version
> alpha d'après ce que je lis). Il se peut en plus que les développeurs
> ne connaissent pas readthedocs (comme moi). Est-ce que ça apporte un
> plus par rapport à la documentation telle qu'on peut la lire sur
> Github ? Il me semble que tout à tendance à se concentrer dans Github
> de nos jours.
> 
> Lorsque j'ai visité le GitHub DP-3T, j'ai vu la description du
> protocole, et des questions dans
> https://github.com/DP-3T/documents/issues où il me semble qu'elles
> sont discutées. Après, il s'agit de discussions techniques: analyses
> de sécurité, faisabilité... Et pour revenir sur les ingénieurs
> (professeurs, doctorants) de l'EPFL, je pense que leur rôle ici, et le
> rôle du Github, c'est le côté purement technique. La présentation
> vulgarisée de l'application, sa diffusion, ce n'est plus le rôle de
> l'EPFL. En fait, le travail de EPFL me semble s'arrêter au protocole,
> l'implémentation étant faite par Ubique Innovation AG à voir les
> commits.
> 
> Concernant la loi, j'ai un peu le sentiment que c'est de la
> gesticulation politique à la française. Je ne vois pas ce que ça va
> apporter de bon. Enfin, je verrai, mais je suis inquiet. Mon
> inquiétude, c'est qu'avec les n'importe qui qui disent n'importe quoi,
> un écho politique soit trouvé, et qu'une "solution politique" soit
> apportée. Tiens, ça commence, un article du Temps
> (https://www.letemps.ch/economie/swisscovid-utiliser-services-damazon-allemagne)
> rapporte que certains craignent le fait que des services Amazon soient
> utilisés. Mouais, sauf que DP-3T a justement été conçu pour que tout
> ce qui est diffusé aux serveurs est publique, destiné à tous les
> possesseurs de l'app du monde entier. Alors que ça passe par Amazon,
> un bunker dans les Alpes ou la NSA, qu'est-ce que ça change?
> 
> Marc Mongenet
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Projet EPFL traçage

J’aimerais rassurer tout le monde: j'avais vraiment bien pris le message 
d'Arnaud. Peu importe qu’il m’ai été adressé ou non, ma réponse était 
bienveillante (je pensais vraiment que mon profil était à chier...).

Donc pas de blème, j'espère tout le monde est détendu. Si j’exprime mon avis de 
façon franche, le minimum que je puisse m’attendre c’est que chacun en fasse 
autant, même à mon sujet.

De toute façon j’ai confiance dans les participants.

Bonne soirée,
L.



> Le 3 juin 2020 à 20:34, Daniel Cordey  a écrit :
> 
> Messieurs,
> 
> Je ne veux pas jouer au gendarme, car je pense que tous les lecteurs de cette 
> liste on passé l'âge des bagarres de cours d'école. Toutefois, j'aimerais 
> rappeler que les critiques doivent être constructives et qu'il est de bon ton 
> d'édulcorer ses opinions personnelles. Je comprends que l'on exprime parfois 
> ses goûts, mais respectons le travail de chacun.
> 
> Tout ça pour dire que les attaques personnelles n'ont pas leur place sur 
> cette liste. Si quelqu'un est en désaccord avec un autre membre, je serais 
> heureux qu'il exprime son opinion par voie de mail privé plutôt que de nous 
> obliger à être témoin d'échanges d'opinions personnelles qui ne concerne pas 
> les membres de l'association.
> 
> Je me permets donc de rappeler la Nétiquette :
> 
> https://fr.wikipedia.org/wiki/N%C3%A9tiquette
> 
> Je remercie ceux qui pourraient se sentir concernés pour leur effort de 
> compréhension.
> 
> Bonne soirée
> 
> dc
> 
> ___
> gull mailing list
> gull@forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull

___
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull

Re: [gull] Projet EPFL traçage

Arnaud,

Vous savez quoi? Vous êtes la deuxième personne qui me dit aujourd’hui que mon 
profil LinkedIn est à chier. Merci de votre commentaire, je suis très sensible 
de votre franchise.

Vous avez probablement raison. J’en ai eu marre et j’ai voulu faire un « coming 
out »… 

Que vous sachiez, toute mon appli de SFK a été développée sur outils Open 
Source. Tout. Alors je ne l’ai pas publiée (parce que c’est en mode cloud et il 
faut bien que je vive...).

Je n’ai pas acheté de données aux fournisseurs de données. Je n’ai utilisé que 
des données en OpenData. Ca n’a pas fait que des heureux.

Donc je suis des votres.

J’aime « mes » banquiers privés, malgré tous leurs travers et toutes leurs 
erreurs, parce que c’est des gens à qui on peut parler. Juste que vous sachiez, 
quand ils vous reçoivent comme fournisseur (à condition de porter une cravate) 
vous avez droit au petit salon, au café et au chocolat :-) Des gens comme ça, 
ça peut pas être totalement mauvais?… Et ils paient bien. 

Et enfin ils ont fait du bon boulot pour lutter contre l’évasion fiscale… à 
partir du moment où ils ont compris que c’était fini le bin’s. Alors je me suis 
dit que j’allais les aider à faire le gros nettoyage.

Donc voilà…

A+
Laurent







> Le 3 juin 2020 à 18:06, Arnaud  a écrit :
> 
> Bonjour Laurent,
> 
> Pour les autres je sais pas, mais moi quand je vois votre profile linkedin, 
> ça me fait un peu froid dans le dos :)
> (le mien questionne aussi les gens, mais différemment ^^ et moi en général ^^)
> 
> Perso, j'aurais aussi hésité à vous répondre, ou j'aurais mis beaucoup de 
> temps à le faire, voir à demander de l'aide pour le faire.
> (et quand il y a "beaucoup de temps à le faire", on peut résumer par "je ne 
> l'aurai pas fait")
> 
> Plus que quand je ne l'avais pas vu...
> 
> Je suis même parti à la recherche de votre compte github (fralau ?), de 
> relire vos messages au GULL que j'ai (depuis 2011),
> à me questionner sur ce que vient faire Linux dans SFK, puis je me suis dit 
> que les gens pouvaient avoir une vie différente professionnellement et 
> personnellement.
> 
> Je ne sais pas si ça vous avance, mais comme j'aime bien vos messages, je 
> vous dis :)
> 
> Cordialement,
> Arnaud
> 
> 
> Le 03.06.20 à 15:40, Laurent Franceschetti a écrit :
>> Wow. Merci Marc,  Tu as raison, on est sur un sujet à haute tension.
>> 
>> Deux mots apparemment anodins de travers, et du coup ça prend une portée. Je 
>> pense que tu as vu juste: les ingénieurs de l'EPFL ne peuvent pas se 
>> permettre de prendre des risques.
>> 
>> C’est là qu’on a un problème. Je pratique github tous les jours, et je n’ai 
>> jamais vu quelqu’un avoir un problème existentiel à répondre à une telle 
>> question (et pour moi, faire de la doc « readthedocs" c’est non seulement un 
>> devoir, mais aussi un sport 
>> <https://mkdocs-macros-plugin.readthedocs.io/en/latest/>). Au pire c’est: « 
>> désolé les gars, mais je n’ai pas le temps/je ne maîtrise pas assez 
>> l’anglais/etc."
>> 
>> Répondre à une question sur « svp mettez un site sur readthedocs » c’était 
>> trop difficile? Ca montre bien combien l’Open Source était à contre-emploi.
>> 
>> Et puis je dois être honnête avec vous: j’ai été un peu sec avec eux, en 
>> tout cas sur LinkedIn. Mais ce qui m’a mis en mode « pétard », c’était ça: 
>> je suis très sensible à tout ce qui touche le code open source et je ne veux 
>> pas qu’une grosse boîte utilise github à son profit. 
>> 
>> Et pourtant, j’étais même prêt à donner le bénéfice du doute à Microsoft, 
>> alors que nombre d’entre nous était sceptique (et l’est toujours)… 
>> 
>> Mais l’EPFL, je ne pouvais pas. Surtout avec l’histoire de la prise de 
>> pouvoir d'Aebischer il y a 20 ans, et le système autocratique qui s’était 
>> installé dans cette école. Je savais que l’esprit Aebischer (brevets, 
>> copains-copain avec la grande industrie, en particulier pharma) ça n’allait 
>> pas avec le logiciel libre. Et avec le nouveau Président Martin Vetterli, ça 
>> a été un peu comme avec Obama: on s’est dit, à ça va changer, etc.
>> 
>> Et là, la première réponse du chef de projet de LinkedIn, c’est du genre « 
>> vous êtes mal informé, vous n’avez qu’à lire les infos sur github ». 
>> Mettons-nous à sa place: la réponse faisait du sens à ses yeux. Mais elle ne 
>> faisait pas de sens dans l’esprit d’une bonne communauté en ligne, surtout 
>> quand on manipule un sujet touchy.
>> 
>> Ce qui m’a surtout énervé, c’est que le gens qui devraient être au courant, 
>> notamment les JURISTES (pour juger de ces aspects), étaient censés

Re: [gull] Projet EPFL traçage

Wow. Merci Marc,  Tu as raison, on est sur un sujet à haute tension.

Deux mots apparemment anodins de travers, et du coup ça prend une portée. Je 
pense que tu as vu juste: les ingénieurs de l'EPFL ne peuvent pas se permettre 
de prendre des risques.

C’est là qu’on a un problème. Je pratique github tous les jours, et je n’ai 
jamais vu quelqu’un avoir un problème existentiel à répondre à une telle 
question (et pour moi, faire de la doc « readthedocs" c’est non seulement un 
devoir, mais aussi un sport 
<https://mkdocs-macros-plugin.readthedocs.io/en/latest/>). Au pire c’est: « 
désolé les gars, mais je n’ai pas le temps/je ne maîtrise pas assez 
l’anglais/etc."

Répondre à une question sur « svp mettez un site sur readthedocs » c’était trop 
difficile? Ca montre bien combien l’Open Source était à contre-emploi.

Et puis je dois être honnête avec vous: j’ai été un peu sec avec eux, en tout 
cas sur LinkedIn. Mais ce qui m’a mis en mode « pétard », c’était ça: je suis 
très sensible à tout ce qui touche le code open source et je ne veux pas qu’une 
grosse boîte utilise github à son profit. 

Et pourtant, j’étais même prêt à donner le bénéfice du doute à Microsoft, alors 
que nombre d’entre nous était sceptique (et l’est toujours)… 

Mais l’EPFL, je ne pouvais pas. Surtout avec l’histoire de la prise de pouvoir 
d'Aebischer il y a 20 ans, et le système autocratique qui s’était installé dans 
cette école. Je savais que l’esprit Aebischer (brevets, copains-copain avec la 
grande industrie, en particulier pharma) ça n’allait pas avec le logiciel 
libre. Et avec le nouveau Président Martin Vetterli, ça a été un peu comme avec 
Obama: on s’est dit, à ça va changer, etc.

Et là, la première réponse du chef de projet de LinkedIn, c’est du genre « vous 
êtes mal informé, vous n’avez qu’à lire les infos sur github ». Mettons-nous à 
sa place: la réponse faisait du sens à ses yeux. Mais elle ne faisait pas de 
sens dans l’esprit d’une bonne communauté en ligne, surtout quand on manipule 
un sujet touchy.

Ce qui m’a surtout énervé, c’est que le gens qui devraient être au courant, 
notamment les JURISTES (pour juger de ces aspects), étaient censés faire quoi? 
Un git clone et trouver les documents?  Ils étaient complètement au pays des 
bisounours...

Le problème était que ça passe au parlement le 8 juin comme un « décret-loi »: 
du coup, l’urgence de la situation ne me laissait pas beaucoup de marge pour 
faire de la dentelle. 

Alors c’est pour ça j’ai lâché quelques grenades sur LinkedIn, avec une 
argumentation juste, mais  simple: "on fait tout dans notre dos ». Je ne 
voulais pas vraiment savoir si c’était bien ou pas bien techniquement, j’ai 
pris ça comme un problème de transparence et d’absence de débat communautaire. 

J’ai dénoncé cet problème à tous mes contacts de la place financière; j’ai 
publié le message du Conseil fédéral, alors qu’aucun de mes contacts était au 
courant (voici le lien, pour ceux pratiquent un peu ce réseau social 
<https://www.linkedin.com/posts/lfranceschetti_message-du-conseil-f%C3%A9d%C3%A9ral-sur-le-syst%C3%A8me-activity-6673578953434787840-uwqo>).

Selon les statistiques, ça a secoué 4000 personnes, 130 avocats, 47 professeurs 
d’universités, 124 directeurs de boîte, surtout à Lausanne, ensuite à Genève, 
troisièmement à Berne (bon c’est toujours à prendre avec les pincettes, mais 
c’est beaucoup en tout cas pour moi).

Alors voilà, je me présente humblement devant vous...

> Le 3 juin 2020 à 13:01, Marc SCHAEFER  a écrit :
> 
> On Wed, Jun 03, 2020 at 12:52:14PM +0200, Laurent Franceschetti wrote:
>>  "I could not find a website with documentation (readthedocs, etc.),
>>  clearly explaining what the app is doing and how it works. Any plans to
>>  publish one in the next days? » 
>> 
>> Ca paraît une question, sensée, modérée (faire un petit site, c'est l'usage
>> pour les projets de ce type). La réponse? zero. Rien. Abonnés absents. 
> 
> Il y a un problème ici: l'interface que tu as utilisée est publique, c'est un
> projet accessible à tous. C'est très surprenant dans le contexte considéré --
> discussion politique en cours -- qu'ils aient publié quelque chose en open
> source (même si c'est une exigence que j'aurais personnellement pour tout
> projet logiciel, en particulier financé par de l'argent public et liés aux
> données personnelles).
> 
> Mais les discussions politiques elles sont plus du niveau marketing et
> relations publiques.  Et pour une institution comme l'EPFL, je doute que cela
> soit fait de manière simple.
> 
> Je doute qu'un ingénieur ait le droit, dans le cadre d'un tel projet, de
> simplement donner les informations dont tu as besoin, a fortiori s'il y a un
> débat politique aux chambres prochainement.
> 
> Je suis d'accord que l'EPFL

Re: [gull] Projet EPFL traçage