C'est aussi ton "éducation" informatique, j'imagine que pour toi comme pour plein de gens qui trempent dans l'informatique, la sécurité doit être forte et du coup un système qui marchote te fait peur.
Bien possible, dans l'informatique on est quand même plus basé sur le contrôle a priori et c'est vrai qu'avec les années on se formate.
Imagine que sur linuxfr pour pas s'emmerder avec un password, on l'enlève. Si il y a des types qui font les cons, la modération s'en occupe. Ok ça peut marcher (avec d'autres inconvénients et d'autres avantages que la situation actuelle), mais tant que je l'aurais pas vécu je trouverai ça pas naturel. ;)
Et ça, tant que les passionnés de sécurité/contrôle ne comprendront pas que le coût de leur idées est supérieure à la gestion des merdes de l'offre qui marche, ils ne comprendront pas pourquoi leurs idées sont rejetées dans la vraie vie. Et non, proposer 36 possibilités dont certaines utilisées par seulement 1% de la population râleuse pour de fausses raisons n'est pas rentable.
La plupart de ces passionnés sont pas idiots, si on leur prouve que le ratio bénéfices/inconvénients est supérieur, je vois pas pourquoi il comprendrait pas.
Ceci dit il y a pas que ça je pense. Ton argent, tu en as sué pour le gagner, souvent des gens voudraient t'en piquer pour une raison ou une autre ; savoir que des gens peuvent "se servir" sur ton compte peut mettre quand même à l'aise de prime abord, avant de savoir précisément comment ça se passe en cas de problème. Je pense que ça explique la réaction épidermique que le prélèvement SEPA provoque parfois.
Il y a pas mal de chose que j'apprends sur ce journal (notamment la facilité de révocation d'un prélèvement SEPA). Peut-être effectivement que c'est de la résistance au changement de ma part.
En ce qui concerne la boulangère, personnellement ça ne me dérange pas, mais il est vrai que c'est peut-être la force de l'habitude.
Tu ne peux pas ignorer qu'une entreprise qui commence à jouer avec les prélèvements SEPA est très très mal barrée.
Ça c'est sûr. Mais pour les gens avec qui elle aura jouer ça peut être vraiment emmerdant pendant un bon bout de temps. Personnellement j'ai pas que ça à faire d'aller récupérer ce qu'on m'a pris abusivement. Note aussi que cette fameuse entreprise peut être en dépôt de bilan et donc plus solvable. Qui paye dans ce cas ? Le contribuable j'imagine.
Des amis m'ont raconté un jour qu'il y a une trentaine d'années EDF avait multiplié par 100 un prélèvement automatique par erreur (saisie du montant en omettant le séparateur décimal). Bien sûr ça c'était résolu au bout de quelques mois, mais tu voyais à leur ton que ça avait pas été de la rigolade.
Personnellement je ne suis pas pour. Quand je vais à la boulangerie c'est pas la boulangère qui se sert dans mon porte feuille, même si elle pourrait, elle sait déjà ce qu'elle a dans sa caisse pour faire la monnaie donc pourrait choisir ce qui correspond.
Note que c'est plus vieux que la mutuelle obligatoire. Il y a également la partie salarié des titres restaurants qui est dans le net imposable, on ne touche pas non plus cet argent.
J'ai déjà vu plein de scripts de ce genre cassés. Au bout d'un certain temps quelqu'un va rajouter un truc entre foobar et if et bing ! Dans l'exemple ça parait évident, quand c'est un script réel plus complexe…
Notez aussi que pour wget, les valeurs de retour différentes de 0 sont toutes des erreurs. Il n'y a pas de cas 'réussite avec une spécificité'.
Donc définitivement je trouve que c'est un hack, un peu comme faire du polymorphisme en C. Oui on peut, mais le langage n'est pas fait pour ça et ça ne sera donc jamais élégant.
Non, le shell gère 255 états de sortie, dont 0 est réservé pour la réussite.
C'est bien ce qu'il dit, il n'y a qu'un état pour la réussite, alors qu'il en voudrait deux :
la réussite sans modification (ok), la réussite avec modification (changed)
Ça en l'état le code de retour de bash ne le permet pas. Note que je ne connais pas Ansible donc je ne sais pas à quoi sert ce distinguo entre un la réussite sans modification et avec.
Android est designé et marketé et suit une stratégie de communication
Les boxes des opérateurs sont designées et marketées et suivent une stratégie de communication
Mon blog est designé et marketé et suit une stratégie de communication
Oui et alors ? Toi tu y vois une causalité, moi j'y vois une simple corrélation. Prouve la causalité.
Et pour les boxes, j'ai jamais vu Monsieur ToutLeMonde se connecter à leur interface web. Ce sont des produits qui sont plutôt là pour faire le job silencieusement.
Au final ce que j'ai constaté dans le libre ou dans l'entreprise, après des dizaines de réunions et de discussions sur ce que l'on devrait faire ou pas, c'est toujours celui qui code en premier en truc utilisable en production qui l'emporte.
Exactement. Les logiciels on les fait pas pour la beauté du geste, mais parce que les utilisateurs en ont besoin. Et les utilisateurs préfèrent un truc existant avec une IHM imparfaite qu'un truc qui n'existe pas avec une super IHM.
Ce que tu comprends pas c'est que c'est une méritocratie. Forke spip, fais-en ta version, publie-la. Si les utilisateurs la trouvent meilleure, il la choisiront. Ca arrive d'ailleurs de temps en temps sur des logiciels de la taille de spip, ou même plus gros (libreoffice par exemple).
Si un designer participe à un projet libre, il faut le voir comme étant d’égale compétence avec un dev, mais dans un autre domaine.
Fabriquer des logiciels c'est une activité majoritairement de développement, avec d'autres activités annexes à côté. Un projet qui n'a que des devs produit des logiciels (même s'ils sont pas beaux), un projet avec que des designers ne produit pas de logiciels. C'est une lapalissade mais ça explique que les devs soient autant considérés (avec raison selon moi).
soit le libre reste dans sa petite mare en disant que la terre entière est trop conne pour comprendre la supériorité des outils sur le monde commercial et rien ne bouge
Rien ne bouge ? De ton point de vue peut-être. Pourtant d'années en années, il y a de plus en plus de libre. T'as ptet un noyau libre dans la poche en ce moment même. Ta box adsl y a quoi dedans ? Ton blog sous Dotclear c'est du propriétaire ?
Bref j'ai trouvé ton billet sympa à lire quand même, c'est toujours intéressant d'avoir l'avis d'un designer. Mais je ne suis pas d'accord avec la majorité des arguments.
J'ai déjà formaté une partition avec toutes mes données non sauvegardées !!!
Moi j'ai carrément redescendue une image vierge sur un serveur de production (croyant la redescendre sur un serveur de test, un peu ce qui est arrivé à Gitlab). Je m'en suis pas rendu compte moi-même mais avant que l'image ai fini de descendre le téléphone a commencé à sonner… Quand j'ai compris j'ai du changer de couleur. Mais heureusement il était environ 11h et la sauvegarde journalière avait lieu à 6h et était parfaitement valide. 5 h de perdues quand même.
Ceci dit quand c'est pas moi qui ai fait l'erreur c'est des moments que j'aime bien. Il faut être super inventif, rapide, et résister à la pression (tous les téléphones sonnent sans interruption, les collègues affluent). La direction qui oublie d'habitude un peu que la technique c'est ce qui rempli nos assiettes reçoit à ce moment-là un petit rappel.
Enfin j'aime bien mais c'est probablement parce que jusqu'à présent ces "petits" problèmes se sont toujours résolu sans drame au final.
J'ai fait quasiment la même chose que toi avec 4 conteneurs LXC (sur 3 dédiés OVH et un petit dédié Online). Ça me permet d'avoir des serveurs FTP en "master-master". J'en ai 3 qui sont à la fois server glusterfs et client glusterfs, le quatrième étant uniquement client. J'ai constaté comme toi que les performances étaient très mauvaises sur celui qui est uniquement client. Par contre elles sont tout à fait correctes sur les 3 autres qui sont aussi serveur. Enfin en tout cas à avec un client FTP je n'ai constaté aucune différence. Quand tu as fait ton test, c'était sur l'un des 2 serveurs ou sur le client ?
Je crois que cette discussion a déjà duré trop longtemps ;) Merci pour les exemples que tu as apporté qui m'éclairent sur des vrais cas d'utilisation. Mais pour ma part je reste sur ma position : ça peut faciliter le boulot du dev (voire de l'admin tant qu'il y a pas de soucis), mais ça ne peut que la dégrader l'aspect sécurité. En tout cas c'est toujours intéressant de discuter avec des devs qui travaillent dans d'autres domaines. Bonne soirée à toi.
Oui, mais il faut programmer ces machins avec des technos hyper anciennes. D'où l'intérêt d'avoir la possibilité d'un environnement de travail différent que celui que propose ta distribution.
J'ai l'impression qu'on ne se comprend pas très bien. ;) J'ai jamais dit que docker n'avait aucun intérêt, il y a plusieurs intervenant du thread qui s'en servent et qui assurent que c'est utile pour eux (dont toi), très bien je n'ai rien contre (et je comprends bien l'exemple du vieux compilo pas de soucis) !
C'est quand ça arrive sur mon PC perso ou sur mes serveurs que ça me pose un problème, parce que j'estime que dans ce cas la sécurité est moins bonne avec ce type de solution qu'avec un dépôt centralisé classique.
Et non la sécurité ne repose pas que sur le fait d'être à jour, je dirais même qu'une bonne sécurité doit prendre en compte l'exploitation d'une faille quelconque pour en limiter ses conséquences. C'est d'ailleurs ce qui se fait en embarqué souvent pour pallier le manque de possibilités pour mettre à jour le système. Genre signature des firmware, cryptographie dans les communications, cloisonnement des applications, réduction des applications au strict minimum ou encore firmware en lecture seule seulement.
Dans la partie à laquelle tu réponds : Une des vraies solutions pour la sécurité, c'est d'être à jour. C'est sûr, il y a les 0 day, c'est pas une solution absolue. Je suis d'accord avec toi sur ce point.
Ensuite, ce n'est pas parce qu'ils sont sur le même réseau que tout doit être sécurisé de la même façon. J'espère bien que l'interface Web de ma banque est bien plus sécurisée que les accès à Linuxfr. Pourtant ils sont sur le même réseau. Et si Linuxfr se fait niquer, honnêtement je m'en fiche (je serais déçu mais ça serait supportable), ma banque pas vraiment.
Donc les objets connectés n'ont pas à avoir la même sécurité que l'application de ta banque, que les accès depuis l'extérieur aux données sensibles d'une grande structure via un VPN, etc. Cela ne signifie pas qu'il ne faut pas traiter la question, mais tu ne peux pas en exiger la même chose. Cela n'a pas d'intérêt.
Les applications lourdes sur chaque poste de travail, les applications d'entreprises non visibles de l'extérieur sans oublier les systèmes embarqués existent et je pense que l'ensemble surpasse ce que tu décris en quantité.
Les applications lourdes sur poste de travail c'est justement ce que je développe. Et la plupart se connectent à un serveur SQL à l'extérieur. D'autres se connectent en SSH pour déposer des documents via SFTP. D'autres encore récupèrent des documents via http.
Celles qui sont non visibles de l'extérieur ne risquent pas de compromission depuis l'extérieur, mais elles en risquent quand même depuis l'intérieur.
Des ordinateurs en entreprises qui ont des fonctions très minimalistes et sans accès au net, il y en a une armée dans la nature.
Ben ce que je constate chez mes clients (ça n'a pas valeur d'universalité on est bien d'accord), c'est justement qu'il n'y en a plus beaucoup et que d'années en années, il y en a de moins en moins.
Ils utilisent aussi une machine à café, un lave linge ou lave vaisselle, une télé ou un téléphone
Les 3 premiers n'ont pas (pas encore plutôt) de prise réseau, la sécurité n'a pas d'importance donc. Pour les 2 derniers, si ils sont connectés ils rejoignent mon cas général. Une télé connectée avec un vieux serveur UPNP doit pouvoir être compromise pour rejoindre un botnet par exemple.
Tu sais que les banques et assurances, ces grosses structure, ont beaucoup de code écrit en COBOL ? Tu sais, ce langage hyper moderne et probablement hyper sécurisé.
C'est pas le langage qui implique la sécurisation. Leur COBOL tourne probablement sur un noyau écrit en C qui n'est pas non plus le langage considéré comme le plus sécurisé, et alors ? Une des vraies solutions pour la sécurité, c'est d'être à jour. C'est sûr, il y a les 0 day, c'est pas une solution absolue, mais pas être à jour c'est courir à la catastrophe.
Pour beaucoup de services la coupure peut coûter plus cher que de laisser tourner malgré les failles (cela dépend évidemment de ce que fait l'application et la machine hein).
Ok pour ça.
Ce qui me gène dans ces technos (je ne nie pas leur intérêt dans certains cas) c'est que j'ai l'impression de les retrouver de plus en plus dans ce que j'appelle le cas général. Et dans ce cas précis, la balance avantages / inconvénients d'un unique dépôt centralisé des dépendances est meilleure que celle des images qui embarquent leurs dépendances.
Mais on ne peut pas en l'état actuel des choses garantir la même sécurité à l'application de la banque et de ta lampe connectée
Le problème c'est qu'elles sont sur le même réseau. Il va bien falloir trouver une solution sinon l'avenir est bien sombre.
Pour moi le cas général à l'heure actuelle c'est les applications dont l'interface est accessible via le réseau (web en général). C'est ça que les utilisateurs utilisent le plus. Effectivement certains utilisateurs (qui sont des devs embarqués) doivent utiliser des vieux compilos pour de bonnes raisons, mais tu vas être d'accord avec moi que c'est une petite proportion des utilisateurs de l'informatique ?
D'autres aussi utilisent des ordinateurs non reliés au net. Mais c'est devenu une petite proportion des utilisateurs également et cette petite proportion devient de plus en plus petite non ?
Cette grande proportions d'utilisateurs utilisent facebook, google, youtube, le site de leur banque, le site des impôts, des forums divers et variés etc…
Toi en tant que dev, j'imagine que tu as dispositions un wiki, un bugtracker, peut-être un serveur de supervision, un calendrier partagé etc. Si tu te connectes à tes objets connectés c'est peut-être par SSH ?
Le cas général ça me semble donc être ça. Et pour ce cas général je pense que la solution d'un unique dépôt centralisé est la meilleure.
Tu sais il y a pas mal d'applications qui restent en vie très longtemps, plus longtemps que plusieurs versions de PHP ou de Python. Quand c'est un peu gros, la transition n'est pas immédiate. Donc tu peux avoir une application qui tourne mais avec des solutions obsolètes oui. On fait quoi dans ce cas ? On coupe tout ?
Si le mainteneur du site de ta banque te dit que la version d'aujourd'hui est trouée mais t'inquiète pas, ils sont en train de développer la correction qui arrivera semaine 53 ça te pose pas de soucis ?
J'ai des applis en php sur mes serveurs installés depuis 2007 ; elles ont du subir plusieurs mises à jour de php, sans problème. Bien sûr ça ne veut pas dire que les problèmes n'arrivent jamais mais je ne les ai jamais rencontré par contre.
J'évite Python pour la raison que tu mentionnes (je dois juste avoir une instance d'un Radicale qui traine).
On entend beaucoup parler en ce moment de la sécurité des objets connectés et ça a pas l'air folichon. Certes c'est pas la faute des solutions comme docker mais cette façon de se dire "l'image faite par le dev embarque toute les dépendances sinon c'est pas assez pratique / on a pas le temps" ça va pas dans le bon sens selon moi.
Il y a parfois des outils, non reliés au réseau, qui sont utiles et dont le portage coût cher par rapport au gain. Car ici les considérations de sécurité sont absentes et donc il faut se coltiner un peu les vieux trucs tant que c'est possible.
On est d'accord, mais c'est un autre cas particulier. Un truc non relié au réseau c'est devenu rare et demain ça sera encore plus rare.
Il y a un temps entre le moment où tu débutes le portage et la fin, et parfois il faut une fonctionnalité ou la correction d'un bogue.
Donc avant d'être portée l'appli est déjà en prod ? trouée ?
Puis il te faut une copie de l'environnement initial pour vérifier que tu n'as pas changé le comportement de l'application dans le portage.
Ok, cas particulier qui concerne les dev.
Pour bien tester et développer, il faut minimiser les différences entre la machine de prod et la machine du développeur.
Dans l'embarqué c'est peut-être le cas je ne sais pas, mais dans le cas général la portabilité est considérée comme une qualité.
Notre désaccord vient de là je pense : dans l'embarqué c'est selon toi une excellente solution et je veux bien te croire, mais dans l'informatique "classique" ce n'en est pas une selon moi. On est formaté par nos domaines d'application respectifs.
Mais pour conclure je préférerai que ce genre de techno restent où elles sont utiles et donc pas sur mes serveurs.
Je veux dire, quand tu utilises un utilitaire comme buildroot, Yocto ou similaires, pour travailler il va utiliser au départ des éléments de ta machine : ton compilateur, les en-têtes et les bibliothèques.
Ok l'embarqué c'est un domaine que je ne connais pas du tout, je veux bien te croire. Ceci dit ça me parait un détail. Qu'il faille une solution particulière pour les types qui utilisent buildroot ou Yocto je le conçois, mais ça concerne une proportion infinitésimal des systèmes et si cette solution a des inconvénients elle ne devrait pas s'échapper de ce périmètre.
Et comment tu gères aussi les différences entre Python, PHP tout ça ? La compilation ne suffit pas, il faut potentiellement récupérer tout l'écosystème en entier. Une distribution offre rarement ce genre de choses nativement, Docker pallie aisément à ce besoin.
Je suis pas sûr de comprendre l'argument ; tu parles par exemple d'une appli web quelconque qui ne fonctionnerait qu'avec une vieille version de php (probablement trouée donc) ? Si oui, il faut modifier l'appli pour qu'elle fonctionne avec les versions actuelles. Faire autrement me semble suicidaire au niveau de la sécurité. Et si on peut pas modifier l'appli pour une raison de budget ou autre, on se dirige dans tous les cas vers des problèmes. Qui mettrait en prod une application web plus maintenue ?
Perso je suis dev (client lourd) ET admin. Ca biaise peut-être (probablement) mon raisonnement, mais je n'aime pas du tout les 'pip install', 'gem install' et compagnie que j'ai déjà croisé. J'ai déjà un gestionnaire de paquet qui est responsable de l'installation des paquets. Et en tant que dev, je tiens particulièrement au principe de responsabilité unique qui est mis à mal avec ce genre de solution.
Dans mon boulot, il m'arrive de devoir travailler (en systèmes embarqués) sur des programmes antédiluviens, qui nécessitent des programmes ou bibliothèques non maintenues dans les distributions principales. On fait quoi ? On jette tout et on dit merde au client et au fournisseur ?
Pourquoi ne pas lier statiquement uniquement les binaires obsolètes dans ce cas ?
Stallman est un intégriste dogmatique, ce n'est pas nouveau. Ça a des avantages et des inconvénients, mais il me semble que le monde du libre (partie GPL) lui doit quand même beaucoup. Linux Apache Firefox et VLC sont compilés avec gcc sous linux par exemple. Plus que ça, sans parler technique, c'est quand même lui qui a lancé le mouvement il y a 30 ans et qui a écrit la GPL v1 si je me trompe pas.
Des gens comme lui sont utiles à long terme, mais on est d'accord qu'ils ne servent à rien sans les pragmatiques qui font eux avancer les choses à plus court terme.
En y réfléchissant je trouve même qu'il a certains points communs avec toi, sur la cohérence intellectuelle notamment. Toi comme lui la priorise par rapport à tout le reste (de ma part ce n'est pas une critique).
D'après tes questions tu sembles débutant. Je ne veux pas te décourager mais ça me semble assez délicat pour un débutant (pas d'offense, tout le monde est passé par là). Peut-être devrais-tu commencer par essayer de piloter ton scanner via sane + bash + zenity ?
J'ai lu ailleurs que le taux de panne Backblaze n'avait pas grand intérêt pour nous simples mortels : en effet, ils utilisent leurs disques dans des racks gigantesques et à ce que j'ai compris c'est une utilisation qui n'est pas prévue pour les disques conventionnels (phénomènes de résonance). On ne peut donc pas en conclure grand chose pour ton type d'utilisation.
Par contre, il y a les chiffres de hardware.fr provenant d'un grand revendeur français (probablement LDLC) : http://www.hardware.fr/articles/947-6/disques-durs.html . Là c'est des types comme toi ou moi qui achetons des disques durs, donc ça semble plus pertinent. Note qu'ils ne parlent que des 3.5" pas des 2.5".
J'ai 2 ou 3 idées un peu différentes, mais la grande difficulté c'est de trouver du temps pour les implémenter.
J'ai une autre question / remarque. Le hash de hash de hash c'est pas un peu spécial ? sha512, c'est pas la concaténation de sha256 et de sha256 de sha256 si ?
Si tu as besoin de 22 flottants, avec 512 bits, tu peux faire des paquets de 19 bits et avec une simple règle de 3 les transformer en flottants entre 0 et 1 avec une précision de 1 / 219 soit environ 2e-6 si je ne me trompe pas. Ca serait pas suffisant ?
[^] # Re: Fake information
Posté par guppy . En réponse au journal Payer ses impôts en choisissant la date. Évalué à 1.
Bien possible, dans l'informatique on est quand même plus basé sur le contrôle a priori et c'est vrai qu'avec les années on se formate.
Imagine que sur linuxfr pour pas s'emmerder avec un password, on l'enlève. Si il y a des types qui font les cons, la modération s'en occupe. Ok ça peut marcher (avec d'autres inconvénients et d'autres avantages que la situation actuelle), mais tant que je l'aurais pas vécu je trouverai ça pas naturel. ;)
La plupart de ces passionnés sont pas idiots, si on leur prouve que le ratio bénéfices/inconvénients est supérieur, je vois pas pourquoi il comprendrait pas.
Ceci dit il y a pas que ça je pense. Ton argent, tu en as sué pour le gagner, souvent des gens voudraient t'en piquer pour une raison ou une autre ; savoir que des gens peuvent "se servir" sur ton compte peut mettre quand même à l'aise de prime abord, avant de savoir précisément comment ça se passe en cas de problème. Je pense que ça explique la réaction épidermique que le prélèvement SEPA provoque parfois.
[^] # Re: Fake information
Posté par guppy . En réponse au journal Payer ses impôts en choisissant la date. Évalué à 2.
Il y a pas mal de chose que j'apprends sur ce journal (notamment la facilité de révocation d'un prélèvement SEPA). Peut-être effectivement que c'est de la résistance au changement de ma part.
En ce qui concerne la boulangère, personnellement ça ne me dérange pas, mais il est vrai que c'est peut-être la force de l'habitude.
[^] # Re: Fake information
Posté par guppy . En réponse au journal Payer ses impôts en choisissant la date. Évalué à 1.
Ça c'est sûr. Mais pour les gens avec qui elle aura jouer ça peut être vraiment emmerdant pendant un bon bout de temps. Personnellement j'ai pas que ça à faire d'aller récupérer ce qu'on m'a pris abusivement. Note aussi que cette fameuse entreprise peut être en dépôt de bilan et donc plus solvable. Qui paye dans ce cas ? Le contribuable j'imagine.
Des amis m'ont raconté un jour qu'il y a une trentaine d'années EDF avait multiplié par 100 un prélèvement automatique par erreur (saisie du montant en omettant le séparateur décimal). Bien sûr ça c'était résolu au bout de quelques mois, mais tu voyais à leur ton que ça avait pas été de la rigolade.
Personnellement je ne suis pas pour. Quand je vais à la boulangerie c'est pas la boulangère qui se sert dans mon porte feuille, même si elle pourrait, elle sait déjà ce qu'elle a dans sa caisse pour faire la monnaie donc pourrait choisir ce qui correspond.
[^] # Re: A quoi ça sert ?
Posté par guppy . En réponse au journal Payer ses impôts en choisissant la date. Évalué à 2.
Note que c'est plus vieux que la mutuelle obligatoire. Il y a également la partie salarié des titres restaurants qui est dans le net imposable, on ne touche pas non plus cet argent.
[^] # Re: Mon positionnement
Posté par guppy . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 2.
Et du coup les constructions classiques ne fonctionnent plus. Par ex :
Si ce que vous préconisez c'est ça :
J'ai déjà vu plein de scripts de ce genre cassés. Au bout d'un certain temps quelqu'un va rajouter un truc entre
foobaretifet bing ! Dans l'exemple ça parait évident, quand c'est un script réel plus complexe…Notez aussi que pour wget, les valeurs de retour différentes de 0 sont toutes des erreurs. Il n'y a pas de cas 'réussite avec une spécificité'.
Donc définitivement je trouve que c'est un hack, un peu comme faire du polymorphisme en C. Oui on peut, mais le langage n'est pas fait pour ça et ça ne sera donc jamais élégant.
[^] # Re: Mon positionnement
Posté par guppy . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 5.
C'est bien ce qu'il dit, il n'y a qu'un état pour la réussite, alors qu'il en voudrait deux :
Ça en l'état le code de retour de bash ne le permet pas. Note que je ne connais pas Ansible donc je ne sais pas à quoi sert ce distinguo entre un la réussite sans modification et avec.
[^] # Re: C'est pas qu'une histoire d'ergo
Posté par guppy . En réponse au journal Le libre et l'expérience utilisateur. Évalué à -2.
Oui et alors ? Toi tu y vois une causalité, moi j'y vois une simple corrélation. Prouve la causalité.
Et pour les boxes, j'ai jamais vu Monsieur ToutLeMonde se connecter à leur interface web. Ce sont des produits qui sont plutôt là pour faire le job silencieusement.
[^] # Re: Ce n'est pas facile.
Posté par guppy . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 3.
Exactement. Les logiciels on les fait pas pour la beauté du geste, mais parce que les utilisateurs en ont besoin. Et les utilisateurs préfèrent un truc existant avec une IHM imparfaite qu'un truc qui n'existe pas avec une super IHM.
[^] # Re: C'est pas qu'une histoire d'ergo
Posté par guppy . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 3.
Salut,
Déjà je te pertinente pour que tu sois visible.
Ce que tu comprends pas c'est que c'est une méritocratie. Forke spip, fais-en ta version, publie-la. Si les utilisateurs la trouvent meilleure, il la choisiront. Ca arrive d'ailleurs de temps en temps sur des logiciels de la taille de spip, ou même plus gros (libreoffice par exemple).
Fabriquer des logiciels c'est une activité majoritairement de développement, avec d'autres activités annexes à côté. Un projet qui n'a que des devs produit des logiciels (même s'ils sont pas beaux), un projet avec que des designers ne produit pas de logiciels. C'est une lapalissade mais ça explique que les devs soient autant considérés (avec raison selon moi).
Rien ne bouge ? De ton point de vue peut-être. Pourtant d'années en années, il y a de plus en plus de libre. T'as ptet un noyau libre dans la poche en ce moment même. Ta box adsl y a quoi dedans ? Ton blog sous Dotclear c'est du propriétaire ?
Bref j'ai trouvé ton billet sympa à lire quand même, c'est toujours intéressant d'avoir l'avis d'un designer. Mais je ne suis pas d'accord avec la majorité des arguments.
[^] # Re: Illustration
Posté par guppy . En réponse au journal De l'importance (des tests réguliers) des sauvegardes. Évalué à 2.
Moi j'ai carrément redescendue une image vierge sur un serveur de production (croyant la redescendre sur un serveur de test, un peu ce qui est arrivé à Gitlab). Je m'en suis pas rendu compte moi-même mais avant que l'image ai fini de descendre le téléphone a commencé à sonner… Quand j'ai compris j'ai du changer de couleur. Mais heureusement il était environ 11h et la sauvegarde journalière avait lieu à 6h et était parfaitement valide. 5 h de perdues quand même.
Ceci dit quand c'est pas moi qui ai fait l'erreur c'est des moments que j'aime bien. Il faut être super inventif, rapide, et résister à la pression (tous les téléphones sonnent sans interruption, les collègues affluent). La direction qui oublie d'habitude un peu que la technique c'est ce qui rempli nos assiettes reçoit à ce moment-là un petit rappel.
Enfin j'aime bien mais c'est probablement parce que jusqu'à présent ces "petits" problèmes se sont toujours résolu sans drame au final.
# .
Posté par guppy . En réponse au message Système de fichier distribué 'rapide'. Évalué à 1.
Salut,
J'ai fait quasiment la même chose que toi avec 4 conteneurs LXC (sur 3 dédiés OVH et un petit dédié Online). Ça me permet d'avoir des serveurs FTP en "master-master". J'en ai 3 qui sont à la fois server glusterfs et client glusterfs, le quatrième étant uniquement client. J'ai constaté comme toi que les performances étaient très mauvaises sur celui qui est uniquement client. Par contre elles sont tout à fait correctes sur les 3 autres qui sont aussi serveur. Enfin en tout cas à avec un client FTP je n'ai constaté aucune différence. Quand tu as fait ton test, c'était sur l'un des 2 serveurs ou sur le client ?
[^] # Re: Dockerfiles
Posté par guppy . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 1.
Je crois que cette discussion a déjà duré trop longtemps ;) Merci pour les exemples que tu as apporté qui m'éclairent sur des vrais cas d'utilisation. Mais pour ma part je reste sur ma position : ça peut faciliter le boulot du dev (voire de l'admin tant qu'il y a pas de soucis), mais ça ne peut que la dégrader l'aspect sécurité. En tout cas c'est toujours intéressant de discuter avec des devs qui travaillent dans d'autres domaines. Bonne soirée à toi.
[^] # Re: Dockerfiles
Posté par guppy . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 2.
J'ai l'impression qu'on ne se comprend pas très bien. ;) J'ai jamais dit que docker n'avait aucun intérêt, il y a plusieurs intervenant du thread qui s'en servent et qui assurent que c'est utile pour eux (dont toi), très bien je n'ai rien contre (et je comprends bien l'exemple du vieux compilo pas de soucis) !
C'est quand ça arrive sur mon PC perso ou sur mes serveurs que ça me pose un problème, parce que j'estime que dans ce cas la sécurité est moins bonne avec ce type de solution qu'avec un dépôt centralisé classique.
Dans la partie à laquelle tu réponds : Une des vraies solutions pour la sécurité, c'est d'être à jour. C'est sûr, il y a les 0 day, c'est pas une solution absolue. Je suis d'accord avec toi sur ce point.
On en reparlera quand ton frigo avec ses 10000 voisins sera en train de faire un ddos sur le site de ta banque. Pour mémoire : https://fr.wikipedia.org/wiki/Mirai_(logiciel_malveillant)
[^] # Re: Dockerfiles
Posté par guppy . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 2.
Les applications lourdes sur poste de travail c'est justement ce que je développe. Et la plupart se connectent à un serveur SQL à l'extérieur. D'autres se connectent en SSH pour déposer des documents via SFTP. D'autres encore récupèrent des documents via http.
Celles qui sont non visibles de l'extérieur ne risquent pas de compromission depuis l'extérieur, mais elles en risquent quand même depuis l'intérieur.
Ben ce que je constate chez mes clients (ça n'a pas valeur d'universalité on est bien d'accord), c'est justement qu'il n'y en a plus beaucoup et que d'années en années, il y en a de moins en moins.
Les 3 premiers n'ont pas (pas encore plutôt) de prise réseau, la sécurité n'a pas d'importance donc. Pour les 2 derniers, si ils sont connectés ils rejoignent mon cas général. Une télé connectée avec un vieux serveur UPNP doit pouvoir être compromise pour rejoindre un botnet par exemple.
C'est pas le langage qui implique la sécurisation. Leur COBOL tourne probablement sur un noyau écrit en C qui n'est pas non plus le langage considéré comme le plus sécurisé, et alors ? Une des vraies solutions pour la sécurité, c'est d'être à jour. C'est sûr, il y a les 0 day, c'est pas une solution absolue, mais pas être à jour c'est courir à la catastrophe.
Ok pour ça.
Ce qui me gène dans ces technos (je ne nie pas leur intérêt dans certains cas) c'est que j'ai l'impression de les retrouver de plus en plus dans ce que j'appelle le cas général. Et dans ce cas précis, la balance avantages / inconvénients d'un unique dépôt centralisé des dépendances est meilleure que celle des images qui embarquent leurs dépendances.
Le problème c'est qu'elles sont sur le même réseau. Il va bien falloir trouver une solution sinon l'avenir est bien sombre.
[^] # Re: Dockerfiles
Posté par guppy . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à -1.
Pour moi le cas général à l'heure actuelle c'est les applications dont l'interface est accessible via le réseau (web en général). C'est ça que les utilisateurs utilisent le plus. Effectivement certains utilisateurs (qui sont des devs embarqués) doivent utiliser des vieux compilos pour de bonnes raisons, mais tu vas être d'accord avec moi que c'est une petite proportion des utilisateurs de l'informatique ?
D'autres aussi utilisent des ordinateurs non reliés au net. Mais c'est devenu une petite proportion des utilisateurs également et cette petite proportion devient de plus en plus petite non ?
Cette grande proportions d'utilisateurs utilisent facebook, google, youtube, le site de leur banque, le site des impôts, des forums divers et variés etc…
Toi en tant que dev, j'imagine que tu as dispositions un wiki, un bugtracker, peut-être un serveur de supervision, un calendrier partagé etc. Si tu te connectes à tes objets connectés c'est peut-être par SSH ?
Le cas général ça me semble donc être ça. Et pour ce cas général je pense que la solution d'un unique dépôt centralisé est la meilleure.
Si le mainteneur du site de ta banque te dit que la version d'aujourd'hui est trouée mais t'inquiète pas, ils sont en train de développer la correction qui arrivera semaine 53 ça te pose pas de soucis ?
J'ai des applis en php sur mes serveurs installés depuis 2007 ; elles ont du subir plusieurs mises à jour de php, sans problème. Bien sûr ça ne veut pas dire que les problèmes n'arrivent jamais mais je ne les ai jamais rencontré par contre.
J'évite Python pour la raison que tu mentionnes (je dois juste avoir une instance d'un Radicale qui traine).
On entend beaucoup parler en ce moment de la sécurité des objets connectés et ça a pas l'air folichon. Certes c'est pas la faute des solutions comme docker mais cette façon de se dire "l'image faite par le dev embarque toute les dépendances sinon c'est pas assez pratique / on a pas le temps" ça va pas dans le bon sens selon moi.
PS : prends pas ça comme une attaque personnelle.
[^] # Re: Dockerfiles
Posté par guppy . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 0.
On est d'accord, mais c'est un autre cas particulier. Un truc non relié au réseau c'est devenu rare et demain ça sera encore plus rare.
Donc avant d'être portée l'appli est déjà en prod ? trouée ?
Ok, cas particulier qui concerne les dev.
Dans l'embarqué c'est peut-être le cas je ne sais pas, mais dans le cas général la portabilité est considérée comme une qualité.
Notre désaccord vient de là je pense : dans l'embarqué c'est selon toi une excellente solution et je veux bien te croire, mais dans l'informatique "classique" ce n'en est pas une selon moi. On est formaté par nos domaines d'application respectifs.
Mais pour conclure je préférerai que ce genre de techno restent où elles sont utiles et donc pas sur mes serveurs.
[^] # Re: Dockerfiles
Posté par guppy . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 2.
Ok l'embarqué c'est un domaine que je ne connais pas du tout, je veux bien te croire. Ceci dit ça me parait un détail. Qu'il faille une solution particulière pour les types qui utilisent buildroot ou Yocto je le conçois, mais ça concerne une proportion infinitésimal des systèmes et si cette solution a des inconvénients elle ne devrait pas s'échapper de ce périmètre.
Je suis pas sûr de comprendre l'argument ; tu parles par exemple d'une appli web quelconque qui ne fonctionnerait qu'avec une vieille version de php (probablement trouée donc) ? Si oui, il faut modifier l'appli pour qu'elle fonctionne avec les versions actuelles. Faire autrement me semble suicidaire au niveau de la sécurité. Et si on peut pas modifier l'appli pour une raison de budget ou autre, on se dirige dans tous les cas vers des problèmes. Qui mettrait en prod une application web plus maintenue ?
Perso je suis dev (client lourd) ET admin. Ca biaise peut-être (probablement) mon raisonnement, mais je n'aime pas du tout les 'pip install', 'gem install' et compagnie que j'ai déjà croisé. J'ai déjà un gestionnaire de paquet qui est responsable de l'installation des paquets. Et en tant que dev, je tiens particulièrement au principe de responsabilité unique qui est mis à mal avec ce genre de solution.
[^] # Re: Dockerfiles
Posté par guppy . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 3.
Pourquoi ne pas lier statiquement uniquement les binaires obsolètes dans ce cas ?
[^] # Re: stat
Posté par guppy . En réponse au journal Visualisation automatique d'un fichier PDF créé avec l'imprimante virtuelle cups-pdf. Évalué à 6.
Avec une syntaxe plus moderne et une protection contre les espaces :
[^] # Re: port salut
Posté par guppy . En réponse au message problème de connexion. Évalué à 1.
Perso le '== true' je trouve ça horrible. C'est pas mieux ça :
Enfin si ça fonctionne, parce que j'en suis pas sûr n'ayant pas fait de php depuis quelques années.
[^] # Re: Ha les intégristes du libre...
Posté par guppy . En réponse au journal De l'autarcie du projet GNU, ou comment Emacs ne veut pas devenir EmacOs. Évalué à 10.
Stallman est un intégriste dogmatique, ce n'est pas nouveau. Ça a des avantages et des inconvénients, mais il me semble que le monde du libre (partie GPL) lui doit quand même beaucoup. Linux Apache Firefox et VLC sont compilés avec gcc sous linux par exemple. Plus que ça, sans parler technique, c'est quand même lui qui a lancé le mouvement il y a 30 ans et qui a écrit la GPL v1 si je me trompe pas.
Des gens comme lui sont utiles à long terme, mais on est d'accord qu'ils ne servent à rien sans les pragmatiques qui font eux avancer les choses à plus court terme.
En y réfléchissant je trouve même qu'il a certains points communs avec toi, sur la cohérence intellectuelle notamment. Toi comme lui la priorise par rapport à tout le reste (de ma part ce n'est pas une critique).
[^] # Re: Utilise libsane
Posté par guppy . En réponse au message Commande scanimage. Évalué à 2.
En fait, Twain a été porté sous linux depuis sa version 2.0 je crois.
Il y a 6 mois à titre professionnel j'ai du réalisé un soft (Qt) de pilotage de scanner via Twain. Mais sous windows. Ce n'est pas trivial. Voici la doc de la version 2.3 : http://www.twain.org/docs/530fe0da85f7511c510004ff/TWAIN-2.3-Spec.pdf
D'après tes questions tu sembles débutant. Je ne veux pas te décourager mais ça me semble assez délicat pour un débutant (pas d'offense, tout le monde est passé par là). Peut-être devrais-tu commencer par essayer de piloter ton scanner via sane + bash + zenity ?
[^] # Re: Taux calculé par moi (à 100% près)
Posté par guppy . En réponse au message Les marques des disques durs : grosse lotterie ?. Évalué à 4.
J'ai lu ailleurs que le taux de panne Backblaze n'avait pas grand intérêt pour nous simples mortels : en effet, ils utilisent leurs disques dans des racks gigantesques et à ce que j'ai compris c'est une utilisation qui n'est pas prévue pour les disques conventionnels (phénomènes de résonance). On ne peut donc pas en conclure grand chose pour ton type d'utilisation.
Par contre, il y a les chiffres de hardware.fr provenant d'un grand revendeur français (probablement LDLC) : http://www.hardware.fr/articles/947-6/disques-durs.html . Là c'est des types comme toi ou moi qui achetons des disques durs, donc ça semble plus pertinent. Note qu'ils ne parlent que des 3.5" pas des 2.5".
[^] # Re: Les différences
Posté par guppy . En réponse au journal ghash: génération d'image à partir d'un hash. Évalué à 2.
J'ai essayé d'implémenter ça vite fait pour rigoler. Résultat 22 nombres entre 0 et 1. C'est pas mieux sans le triple hash ?
Exemple :
[^] # Re: Les différences
Posté par guppy . En réponse au journal ghash: génération d'image à partir d'un hash. Évalué à 1.
J'ai 2 ou 3 idées un peu différentes, mais la grande difficulté c'est de trouver du temps pour les implémenter.
J'ai une autre question / remarque. Le hash de hash de hash c'est pas un peu spécial ? sha512, c'est pas la concaténation de sha256 et de sha256 de sha256 si ?
Si tu as besoin de 22 flottants, avec 512 bits, tu peux faire des paquets de 19 bits et avec une simple règle de 3 les transformer en flottants entre 0 et 1 avec une précision de 1 / 219 soit environ 2e-6 si je ne me trompe pas. Ca serait pas suffisant ?