gaaaaaAab a écrit 1393 commentaires

Je suis pour avoir le choix, mais donner des choix techniquement "moins bons" que ce qu'on nous propose, c'est quand même un comble non ?

On pourrait transposer cette phrase en changeant un peu le contexte. Par exemple Open Office serait sysv, et MS Office serait systemd, ou alors FreeBSD serait sysv et MacOs serait systemd, ou autre. Cherchez pas trop derrière les exemples, y a pas d'intention de troller de ma part. Ce sont des exemples qui, je pense, lèvent un léger doute sur la pertinence de ta question, ou donnent un élément de réponse :-)

0ui. Et pendant ce temps, pleins de boites migrent tout leur SI dans le Claude …

c'est vrai que tu vas accéder à tes e-mails en clair sur gmail dans une connexion sécurisée en HTTPS, mais il y a aussi le transfert en SMTP entre l'expéditeur et la boite mail. Et c'est à ça que je pensais en parlant d'envoi en clair. J'aurais pu être plus précis.
Du coup, je me rend compte qu'il y a SMTPS, mais je n'ai pas l'impression que ça soit très répandu. Et puis une fois que tu t'es connecté à ton serveur SMTP en ssl, tu n'as pas la garantie que l'échange entre le serveur SMTP que tu a joins et le serveur d'email de destination sera aussi encapsulé dans une canal sécurisé.

Donc oui, dans un contexte pro, dès qu'il y a une tierce partie, perso, je ferais du GPG.

Je ne l'ai pas précisé dans mon premier commentaire, mais c'est sûr que limiter le nombre d'intermédiaires réduit la surface d'attaque, dont il faudrait éviter autant que possible. Après, il faut trouver le compromis entre sécurité et utilisabilité.

A titre personnel, dans un cas similaire, je n'utiliserais qu'une boite pro sans redirection, sous réserve d'avoir un accès à distance au serveur de mail (que ça soit en imaps depuis une ip public ou sur un VPN). Ou alors, si le serveur e-mail est opéré par le client et est difficilement accessible, sur un serveur de mail opéré par ta boite avec imaps/vpn. Je ne ferais pas le compromis d'utilisabilité que tu décris avec un fournisseur d'e-mail tierce à la gmail, mais je veux bien admettre que je suis un peu plus parano que la moyenne :-)

d'un point de vue légal/contractuel, je ne sais pas - et c'est ce que je cherche à identifier.

alors demande à un juriste, parce que demander çà à linuxfr, c'est l'équivalent de demander un avis médical à doctissimo :-)

Je suis preneur de vos retours par rapport à cette problématique, en particulier des retours d'expériences réelles.

je suis un peu à côté, vu que ceci n'est pas un retour d'expérience réelle, ni l'avis d'un juriste.

est-ce que le fait d'utiliser un service externe pour gérer des données confidentielles peut être problématique ?

si les informations transitent en clair par e-mail, la question du prestataire fournissant la boite e-mail parait assez accessoire. Et si les infos sont chiffrées, le fait que ça soit gmail ou un autre est sans incidence.

Pour le dire autrement, dans une situation analogue, je ne m'autoriserais une redirection de ce type que si elle n'est pas strictement inférieure à tous les chaînons intermédiaires en terme de confidentialité.

Ta remarque n'est pas sans mérite, mais je ne pense pas qu'elle se tranche aussi définitivement que ce que tu sembles penser.

C'est une grande question de l'éducation. Enseigner des outils directement utilisables professionnellement, ou utiliser des outils moins directement utilisables, mais plus pédagogiques, pour aboutir à une meilleure compréhension de la matière.

En prépa et école d'ingé d'info (au passage, programmeur et ingénieur, c'est pas incompatible), j'ai fait un peu de programmation fonctionnel (ocaml et lisp). Jusqu'à présent, je ne m'en suis pas servi professionnellement, mais je suis content d'y avoir été exposé pendant mes études.

En enseignant le python, en ne gardant que le paradigme procédural, si vous voulez.

J'imagine que c'était un exemple vite fait d'une piste que t'as pas trop creusé. Je relève juste parce que ça me parait être une mauvaise idée d'enseigner le Python en se restreignant au paradigme procédural. Ça ferait des très mauvais développeurs Python.

et des trolls sur linuxfr ;-)

je suis allé regarder le man de g++. Effectivement, -permissive permet de compiler du code non conforme. Donc, un point pour toi, et je suis surpris :-) Je ne dirais donc plus que C est un sous-ensemble de C++.

Ça peut avoir du sens de regrouper C et C++ dans certains contextes.

Ça m'étonnerait un peu si c'était pas du C++ valide, parce que il me semble que la compatibilité avec le C était un principe très significatif lors de la conception du C++.
Mais comme je pratique pas beaucoup le C++, je ne sais pas trop. En tout cas, avec le drapeau -fpermissive, g++ considère que c'est un warning, et accepte de compiler.

bien vu !
Je me suis arrêté à "le compilo donne le même warning pour les deux", mais c'est vrai que ça ne suffit pas.
Cela dit, même entre deux versions d'un seul compilateur sur un seul langage, on pourrait aussi avoir des comportements différents (surtout sur des comportements non définis).
Dans l'absolu, il faudrait en fait préciser le couple (langage, compilo) pour chaque exemple, mais ça devient vite vachement moins facile à appréhender.

Sur le fond du journal, c'est un détail, mais si le C est du C++ valide, le contraire n'est pas vrai. Pour avoir un exemple en C/C++, il aurait fallu préférer une version en C avec du bon vieux stdio.h et du printf :-)

Avec la suite gcc/g++ 6.3, le warning est identique en C (ce qui n'est pas du tout surprenant).

sinon, dans cette exemple, tu as écrit un décalage à gauche au lieu d'un décalage à droite (j'imagine que tu t'es laissé embarquer par l'opérateur du cout)

J'avais vu passer SEUM, mais je n'ai pas pris le temps de regarder de près. Pour moi, c'est vraiment la qualité du level design qui fait la richesse de Deadcore. Mais, trop se renseigner avant sur ce que ce genre de jeu propose en la matière, ça peut casser un peu le plaisir de la découverte des niveaux. Cela-dit, tu fais bien de me remettre SEUM en tête, je vais creuser un peu, ça peut effectivement me plaire !

Oui. Je n'ai pas retenu shadowrun. D'une part parce que je ne voulais faire une liste de plusieurs dizaines de titre. Et aussi parce qu'au delà des aspects RPG (progression, quêtes) et du thème (cyberpunk) qui contribuent à rendre ces jeux sympas, je trouve les mécaniques de combat moins riches et moins profondes que les deux que j'ai cité.
Je n'avais pas fini shadowrun returns, mais dragonfall était incontestablement meilleur, et j'ai bien apprécié hong-kong aussi.

Après, les goûts et les couleurs toussa ;-)

j'ai aussi bien aimé the Talos principle.

il y a aussi d'autres bons jeux indés. Je me restreins volontairement à une poignée. Liste évidemment subjective, et contenant des titres vraiment de niche. Si ça vous fait de l'oeil, renseignez vous un peu pour voir si ça peut vous plaire (en dehors du fait qu'un seul de cette liste soit libre). Je met des "genre" pour donner une idée, mais ça correspond objectivement pas à grand chose.

• tactique tour par tour : darkest dungeon et invisible Inc (y'en a deux, c'est mon genre de prédilection)
• super hexagon : open hexagon : clone libre de super hexagon
• platforme FPS : deadcore (assez orienté speedrun, par un studio français)
• twin stick shooter : the binding of isaac
• shmup : steredenn (parce que j'aime la bande son, la direction artistique, le gameplay, et par un studio français aussi)
• WTF: The Stanley Parable

et j'ai envie de citer sunless sea pour l'ambiance lovecraftienne. mais je pense que les mécaniques de jeu ne plairont pas à tout le monde. En tout cas, la première fois, je n'ai pas trop accroché. Et c'est seulement en lui redonnant sa chance un an plus tard que je me suis vraiment plongé dedans.

en gros apache n'attend pas assez longtemps que ton process wsgi.py renvoie ses reponses
soit faut que ton python tourne plus vite, soit qu'apache soit plus patient

pas forcément. apache attend des données sur la sortie standard du process fils. Si apache n'a pas de réponse, ça peut aussi être parce que le fils s'est vautré, ou ne produit pas une sortie au format attendu par apache (manque de saut de ligne après les en-tête http, lignes de log du process redirigées vers la sortie standard, …). Et bien sûr, ça peut être que le traitement est trop long comme tu le mentionnes.

Le fait qu'il y ait des messages d'erreur différents selon les cas, ça pourrait aussi être que le process fils renvoie du junk, mais que de temps en temps, ça ressemble suffisamment à ce qu'apache attend pour qu'il lise une taille random (et du coup, ça marche pas).

Ça serait intéressant de voir le détail de ce que le process wsgi produit comme sortie.

En passant, Python2 renvoie -1, mais Python3 renvoie 0

Histoire de pinailler un peu, les deux commandes sont fonctionnellement équivalentes, mais à choisir, je prendrais toujours le "sort -u". Il me parait préférable d'utiliser une seule commande au lieu de deux : un fork en moins, et une gestion d'erreur plus facile si on décide d'en faire. Sur un script utiliser une fois, on s'en fout un peu, mais si ça doit atterrir dans un truc lancé régulièrement, c'est bien d'avoir ces considérations en tête.

J'étais tombé sur un post d'un blog qui présentait less +F, et c'est de la grosse balle. Ça permet de se mettre en attente sur un fichier (comme tail -f), mais on peut aussi interrompre l'attente pour se balader dans le fichier, puis se remettre en attente sur le fichier. Ça remplace très avantageusement tail -f /var/log/messages par exemple.

$ while [ 1 ]; do date >> log_file; sleep 1 ; done &
[1] 12294
# je coupe des lignes, la commande suivante affiche en fait less sur tout le terminal
$ less +F ./log_file
Tue Oct 11 13:31:37 CEST 2016
Tue Oct 11 13:31:38 CEST 2016
Waiting for data... (interrupt to abort)
# sur pression de Ctrl-C
Tue Oct 11 13:32:15 CEST 2016
Tue Oct 11 13:32:16 CEST 2016
Tue Oct 11 13:32:17 CEST 2016
Tue Oct 11 13:32:18 CEST 2016
Tue Oct 11 13:32:19 CEST 2016
./log_file (END)
# on peut naviguer dans le fichier de log comme on fait habituellement dans less.
# pour reprendre la mise à jour du fichier, il suffit de se déplacer en fin de fichier (touche F)
Tue Oct 11 13:33:34 CEST 2016
Tue Oct 11 13:33:35 CEST 2016
Tue Oct 11 13:33:36 CEST 2016
Tue Oct 11 13:33:37 CEST 2016
Waiting for data... (interrupt to abort)
# et hop, de retour sur le lecture des nouvelles entrées dans le fichier

ah ok. c'est ton utilisation du présent qui m'a fait penser que tu avais raté l'info.

ils ont fait ça longtemps, mais depuis que ça a été racheté, les repreneurs ont immédiatement arrêté ça. En tout cas, ils ont communiqué dessus très vite, et depuis, les quelques fois ou j'ai regardé un truc hébergé chez eux, ça avait l'air ok.

j'ai retrouvé l'annonce

je me réponds tout seul, parce que pourquoi pas. Dans ce que j'ai écrit, j'ai conclus un peu vite que les infos du whois sont publiques. Il faudrait voir si "exiger que des infos soient publiquement disponibles" en fait des informations publiques. Perso, je pense que oui, mais je reconnais que ça pourrait ce discuter.

Je suis moi-même propriétaire d'un nom de domaine,

pas tout à fait, tu en es plus le locataire que le propriétaire ;-)

Toutes les informations accessibles via un whois sont publiques
Or nous avons obtenues ces informations via un whois
Donc ces informations sont publiques.

J'avoue que pour moi, il était acquis que les infos d'enregistrements de noms de domaine étaient publiques. Du coup, je suis allé jeter un œil sur wikipedia, et dans le paragraphe criticism, il y a :

Currently the Internet Corporation for Assigned Names and Numbers (ICANN) broadly requires that the mailing address, phone number and e-mail address of those owning or administrating a domain name to be made publicly available through the "WHOIS" directories

traduction suivant la méthode rache :

Pour le moment, l'ICANN exige que l'adresse postale, le numéro de téléphone et l'adresse e-mail des détenteurs ou administrateurs de noms de domaine soient publiquement disponibles dans les répertoires WHOIS.

Ce qui m'inspire deux commentaires :
- aujourd'hui, le contenu du whois est bien une information publique,
- beaucoup de gens (dont l'ICANN) considèrent que c'est un problème (cf ce paragraphe )

Je comprends l'intérêt (voire la nécessité) de protéger les informations personnelles. D'un autre côté, l'espace des noms de domaine est un espace commun. Quand quelqu'un s'en approprie temporairement un morceau (en enregistrant un nom de domaine), ça ne me paraît pas non plus totalement illégitime d'avoir un moyen de l'identifier.

Bref, pour citer encore wikipedia, mais la page française ce coup-ci :

Le choix de ce qu'on publie reste une des questions politiques les plus brûlantes pour un registre Internet.

L'argument de reflets.info est que ces informations ne sont pas privées car elles ont été récupérées par un whois.

non, la question du moyen de les récupérer n'est absolument pas la justification avancée. Dans le paragraphe qui commence par "Pour ceux qui ne savent pas ce que c’est, nous allons l’expliquer." , je cite :

Ces informations sont publiques et une simple recherche permet de les afficher. Celui qui les fournit sait qu’elles seront publiques.

Ils n'ont pas écrit que ces infos sont publiques parce que faciles à obtenir, mais et faciles à obtenir.

En règle générale, ça serait vraiment bien de poster les sorties correspondant effectivement au script décrit. Là, vu le script, dans la ligne générée, archive.tar.gz devrait plutôt ressembler à archive_2016-09September-18_002627 (curieux format de date). D'autre part,

'--newer-mtime="2016-09-18' '00:26:27"'

ne correspond pas non plus à $g tel que g est défini.

Sinon, le calcul de ddate peut être légèrement amélioré.
On peut identifier l'entrée qu'on veut garder avec ls avant de transmettre le résultat à stat (du coup, stat ne traite qu'un seul fichier au lieu d'une liste).
Pour garder la première ligne d'une liste, sed -n '1 p' fonctionne, mais parcourt toute la liste. Il vaut mieux utiliser head (ce qui améliore également la lisibilité).
Sur le plan cosmétique, je préfère évaluer avec $(…) plutôt que \'…\', mais là, c'est plus une question de préférence personnelle.

Bref, j'écrirais plutôt :

ddate=$(stat --printf '%y#%n\n' $(ls -t $a/*$t* | head -1) | cut -d "." -f 1)

Au final, le nombre de commande lancées est le même, mais seul ls travaille sur une liste, les autres commandes ne traitent qu'une seule entrée. Sur des répertoires avec de nombreux fichiers, la différence en temps d'exécution peut être significative.

Ce n'est effectivement pas le même fichier de référence.
Pour une fois que je commentais mon code ;-)

je vois deux façons de le faire directement dans find.

En excluant le fichier de référence :

find . -maxdepth 1 -name "complete*" ! -newer complete_2016-09-11.tar.gz ! -name complete_2016-09-11.tar.gz

ou en prenant l'avant-dernier fichier comme référence :

find . -maxdepth 1 -name "complete*" ! -newer complete_2016-09-10.tar.gz

Personnellement, je préférerais la seconde forme, et je garderais plus qu'une seule sauvegarde complète s'il n'y a pas de problèmes d'espace disque.