En fait tout cela me fait m'interroger sur le concept même
d'Ethereum. La blockchain c'est cool pour enregistrer des données
statiques comme des transactions, mais pour du code ? Par son
concept même, on en pourra jamais mettre à jour le code. Il faut
donc être sacrément sûr de son code pour commencer à l'utiliser,
parce qu'on ne pourra alors plus le changer. Et même si on prouve
le code à 100%, on n'est pas à l'abri d'une erreur humaine (ici,
oublier d'appeler une méthode d'initialisation).
Ce qui en soit est pas si différent du type de déploiement qu'on voit pour de l'embarqu^W IOT. Et dire qu'on peut pas mettre à jour, c'est aussi un peu trompeur. Tu pourrais si tu avais le controle de la blockchain entiére. C'est certes sans doute impossible pour une blockchain publique, mais je suis sur qu'il existe des applications ou tu as ta propre blockchain privé et ou c'est faisable, ce qui limite quand même les risques (un peu comme faire un git push -f, ça passe mieux quand tu es seul)
Tout d'abord, au niveau local il peut y avoir une sécurisation
des données grâce à du RAID
Le RAID, j'ai pas tendance à voir ça comme une sécurité des données plus que s'assurer de la disponibilité et que l'uptime ne prends pas un coup si un disque tombe (en partant du principe que tu as un niveau de raid différent de 0). Parce que le RAID sécurise pas vraiment contre un effaçage par erreur ou contre un bug du FS :/
En fait, j'ai vraiment tendance à ne pas aimer qu'on parle de sécurisation sans dire "contre quoi", parce que ç'est indispensable pour savoir ce qui manque, surtout si c'est à destination des membres, qui vont pas forcément avoir le réflexe de penser "ok, qu'est ce qui se passe si tel truc arrive".
Entre site, la réplication des VM ne se fera qu'en asynchrone.
Pour la réplication, le plus simple est de faire un snapshot de
la VM puis de la répliquer.
Plus simple oui, mais je suis pas sur que ça marche à 100%. Encore une fois, tu peux avoir le disque dans un état non consistant. Et ça, c'est quand tu as pas des données sur plusieurs disques (exemple, un serveur sql partagé et X serveurs webs avec des applis différentes), parce que ça devient vite compliqué Ensuite, je donne le pire cas possible, il est possible que ça marche suffisamment bien et que tu puisses corriger à la main le reste du temps (e.g, aller tripoter dans la DB si besoin), donc je suppose qu'il ne faut pas faire une usine à gaz.
7 serveurs physiques, ça me parait un chouia trop. Tu peux t'en sortir avec moins si tu mets les OSD et les moniteurs sur les mêmes machines, en partant du principe que tu as dimensionné ça de façon à ce que ça passe (genre, avoir un disque, asse de ram et un CPU par OSD, et donc un CPU et assez de ram pour le moniteur, avec "assez" documenté sur ceph.com).
Ensuite, ça dépend aussi de la topologie réseau que tu va mettre des patterns d'accès, de la volumétrie, des perfs que tu veux avoir.
Par exemple, ça parle de réplication, mais est ce que l'idée est d'avoir une réplication en temps réel (et donc synchrone) auquel cas les performances vont chuter si tu fait ça sur un site distant, ou d'avoir des trucs asynchrones et de la magie pour revenir quand ça explose ?
Il n'y a pas spécialement de discussion sur la volumétrie non plus ou la question du lien entre les sites.
Le type de données va aussi importer. L'utilisation de GlusterFS pour stocker des images de VM fait parti des cas supportés par le projet (vu que c'est des gros fichiers, ç'est assez performant), et le projet ovirt le supporte. Mais de la même façon, des gens placent le stockage en mode bloc dans Ceph.
Mais si le but est d'avoir des machines dont tu fait des snapshot, je pense que tu peux pas éviter d'aller dans la VM et faire des choses pour que les données sur le disque soit cohérentes.
J'ai par exemple du mal à voir comment une synchro des blocs ne va pas corrompre une base de données et une appli web si ça pête au mauvais moment, vu que c'est rarement atomique (sauf à tout mettre dans la base de données, et à avoir des transactions, mais je pense que pas grand monde vérifie ça, et qu'à choisir entre une appli qui va exploser sous un cas critique, et pas d'appli, les gens prennent l'appli quand même).
Du coup, si tu fait la redondance au niveau au dessus, tu as moins besoin au niveau en dessous.
Donc les besoins vont dépendre des applis. Est ce qu'il faut avoir de la HA automatique, ou remonter rapidement suffit ? Comment le systéme va devoir se débrouillé en mode dégradé ?
Pour reprendre l'appli d'exemple de toute à l'heure, une solution de stockage classique avec une base SQL répliqué suffirait, avec des frontends sans état, pas besoin de sortir des trucs complexes (pour peu que les VMs soit identiques)
Et sinon, on est en 2017, les archis à base de conteneurs ont le vent en poupe, et ont le bon gout de pousser à séparer données et codes, ce qui permet aussi de se focaliser sur ce qui AMHA importe, les données. Je dit pas que c'est une bonne idée, mais je pense que c'est pas déconnant de regarder. Et pas regarder docker tout nu, plus des choses comme kubernetes/openshift ou mesos, avec idéalement une stack supporté.
Et la partie "pas de java" me parait quand même restrictive et sans doute mal exprimé. Parce que je suis sur que pour certaines choses, y a sans doute d'autres languages qui vont faire pire que java (cough golang et rust pour du statique, ruby pour tirer 5T de deps), donc je suis sur qu'il y a plus précis comme demande.
Ben si c'est justement parce qu'on bosse dans l'IT qu'on bondit sur notre chaise.
Arrête ton char, tu sais très bien que dans l'IT, tu as toujours un delta énorme entre ce que tu voudrais faire, et ce que tu peux faire dans les temps.
Et la, c'est pareil, sauf qu'en plus, tu as moins de monde et de temps.
Vous bossez dans quel boite pour que tout les serveurs soient tous sur la dernière version, pour ne pas avoir des tonnes d'autres trucs à faire ?
Parce que les clients dont j'entends parler, c'est migration à RHEL 7 2 ou 3 ans après la release, parfois certains envisagent passer à RHEL 6. C'est des serveurs encore en 12.04 ou 10.04 que les gens peuvent pas migrer rapidement, parce que tout à changer et y a pas de budget.
Y a aucun des admins qui est sur le projet à temps plein, et pire encore, aucun qui est uniquement contributeur à l'admin de l'infra.
Et même au delà de ça, tu regardes quand Gitlab a eu un gros souci, des gens ont dit "ça arrive à tous" (sur twitter) et ça a globalement été positif. Ici, c'est juste du fiel et du purin sur des bénévoles en sous effectif à cause du stress, pour un souci qui n'a pas eu lieu.
Mais c'est quoi comme ambiance de merde dans ce coin du logiciel libre ?
Au passage, pour avoir regarder le fonctionnement des dits bots qui se baladent (c'est pas dur, tu peux juste mettre un pauvre honeypot ssh, y en a des tonnes et c'est facile d'en écrire un avec twisted), la majorité des bots vont tentés d'exploiter des failles archi courantes.
Soit des mots de passes par défaut et/ou faibles (cas des bots ssh, genre mirai), soit des failles connus dans des softs classiques (style wordpress), soit shellshock.
Que je sache, rien de tout ça ne s'applique à ce serveur:
- c’était du mod_perl, on évite globalement shellshock via mod_cgi
- pas de wordpress dessus (que je me souvienne)
- le ssh est par clé uniquement dans mon souvenir
Donc sauf erreur de ma part et sur la base des bots que je voit sur mes serveurs, le risque est globalement faible.
Ensuite, tu as peut être sans doute d'autres infos qui te permettent d'être plus affirmatif que moi, auquel cas je suis sur que tu peux les partager pour faire avancer le débat de façon constructive.
La gestion d’une infrastructure c’est un métier, n’importe qui
ne peut pas le faire. Vu les commentaires, on est clairement
face à n’importe qui.
C'est assez hautain et puant comme commentaire, j'aurais honte de parler sans savoir à ta place.
L'équipe d'admin sys de Mageia au début, ç'était 10 personnes. Sur les 10, je compte 7 admins de profession (2 dans une université, 1 chez un telco, 2 dans 2 multinationals du secteur informatique bien connus).
Donc non, je pense pas qu'on est face à n'importe qui.
C'est pas le manque de compétence. C'est le manque de temps et de personne, vu qu'au fur et à mesure des années, 3 (ou plus) ont eu des gamins, 3 sont parti en burnout et/ou depressions (parfois pas à cause du projet) et parfois revenus, 3 ont changés de taf (et on arrêté le projet). Et comme tu dis, l'admin sys, c'est un métier, et personne n'est venu faire un métier gratuitement sur son temps libre pour aider (chose plus dur qu'être désobligeant envers les autres, je le conçoit).
C'est peut-être la le problème : ne pas avoir su s'arrêter avant
que ça devienne dangereux au niveau sécurité.
S’arrêter de faire quoi ?
S’arrêter de filer du temps gratos ?
S'arrêter de faire le travail en risquant de se faire insulter sur linuxfr ? Qu'est qui aurait du être arrêter ?
Je crois qu'il y a un problème de compréhension : le sujet
n'est pas que les bénévoles doivent être des esclaves, mais
qu'il font croire qu'ils font ce qu'il faut pour protéger un
minimum, le sujet est qu'il semble impossible de se dire "ok,
on n'a plus assez de monde, on ferme avant que ça casse".
Ça se voit quand même que tu as jamais bossé dans un projet d'envergure avec du monde, voir même fait de la gestion de risque. Deja, tu va pas dire "on ferme le projet, on a un serveur pas à jour", surtout quand, comme dit par Pascal, un plan pour la mise à jour est en cours. Peut être qu'envoyer chier le monde est trivial pour toi, mais c'est pas le cas de tout le monde. Donc oui, les gens vont pas arrêter quand il est trop tard, et surtout pour Mageia (j'ai pas besoin de parler de l'histoire de la distribution).
De surcroit, c'est quand "trop tard" ? Y a pas de moment exact pour ça
Pire, une fois que ça a été public, ça n'a pas été coupé dans > l'heure.
Ça a toujours été publique pour qui sait regarder. Et encore une fois, l'attente que les bénévoles doivent réagir dans l'heure et rapidement est une source de stress. Et le stress et le burnout dans le libre est un souci.
ça ce n'est pas la faute de ceux qui ont montré le problème.
Mais le souci est pas de signaler un problème.
Le souci, c'est de signaler un problème connu depuis longtemps et de croire qu'aller insulter les gens pour forcer la migration va aider.
Coquelicot-bleu a bien dit qu'ielle utilise pas la distribution, donc ielle n'a même pas l'excuse de faire ça pour son propre bénéfice. Les admins étaient déjà au courant. Il ne faut pas non plus prendre la profession pour des idiots, on sait exactement ce qui est pas à jour, on sait ce qui est risqué, la dette technique, on a ça en tête tout les jours.
Donc ce que ça va donner, c'est une migration potentiellement rushé, des attaques sur Linuxfr sur les gens qui font le travail, et sans doute un pas de plus vers le burn out pour eux.
Tout ça pour une attaque qui n'a pas eu lieu, pour un serveur qui n'est pas si critique que ce qu'il veut faire croire (et moi, je sais comment est architecturer le système, je sais ou sont les points faibles qu'on a pas pu renforcer de mon temps, vu que j'ai été un de ces architectes). Oui, ça aurait du être mis à jour plus tôt, mais "c'est la vie", surtout si les bénévoles sont pas des esclaves (parce que bon, dire "faut faire ça, et fait ça gratos et plus vite", ç'est quand même une forme de pression psychologique assez mauvaise).
Un serveur troué qui gère l'interface d'admin des comptes ainsi
que leurs clefs ssh et toi tu vois pas où est le problème ?
Le serveur est juste un client ldap élaboré. Donc si jamais tu prends le contrôle du dit serveur, tu va pas avoir plus de contrôle que si tu attaques le ldap directement. Tu va avoir en effet une vue sur ce qui se passe, mais c'est autre chose.
Au hasard ? Une petite modif dans le code de l'appli de
gestion de comptes utilisateurs pour logger les
logins/password, ne reste plus qu'à attendre qu'un admin se
connecte et le tour est joué
Puppet va reverter le changement (déploiement auto depuis git/svn), et/ou le signaler. Tu devrais pas faire tes attaques au hasard, ça a pas l'air de marcher dans la vraie vie.
Ok, on modifie la conf apache pour logger les données POST, et
voila.
Puppet va reverter le changement, et/ou le signaler (c'est le but de puppet).
Bien sur, tu peux couper puppet, mais dans ce cas, ça va lancer une alerte assez vite sur le monitoring pour dire que "tel client n'a plus puppet qui tourne"
Donc la fenêtre de tir est assez courte (grosso modo, puppet se lance toutes les heures), il faut que tu fasses une attaque et que dans l'heure, un des 5 ou 6 admins se connecte pour changer sa clé sur l'interface (et pas ldapvi).
Ou que tu attaques de façon plus spécifique pour pas te faire choper (ce qui est faisable, même si j'ai plus les détails en tête, j'ai tenté de fermer ça autant que possible).
Je ne dit pas que c'est impossible, mais on sort très clairement des attaques de script kiddies. De mon expérience (ie, à dealer avec des vraies attaques et à faire du forensic), puppet est déjà au delà des capacités des admins moyens (sinon, je pense qu'il y aurait eu plus de patch), et donc du script kiddie moyen. J'ai eu à dealer avec des serveurs compromis, et en général, la ligne de commande classique est souvent déjà au delà des capacités de l'attaquant lambda, comme n'importe qui qui a pu lire un .bash_history d'un serveur compromis ou d'un honeypot a pu le constater.
Soit tu tombes sur des gens motivés et avec des ressources, et c'est globalement foutu si tu as pas autant de ressources en face (une équipe legere d'attaquant, ça se chiffre dans les 2 millions par an, cf https://medium.com/@thegrugq/cyber-ignore-the-penetration-testers-900e76a49500 ). Soit tu va tomber sur des attaquants moins staffés, et en général, c'est des boulets qui vont faire du bruteforce classique. Il y a fort peu de cas entre les 2 (ou personne n'en parle, mais c'est un autre débat).
Donc si le but est de rajouter une backdoor, c'est infiniment plus sur et plus rapide de juste devenir packageur et de rajouter ça dans la distribution. Genre en changeant un tarball d'un soft utilisé partout mais pas signé (y en a un paquet). Ça ne serait pas pérenne, mais sans doute discret.
Ou voir même, de devenir admin. Il y a tellement besoin d'aide que je suis sur qu'une personne en 2 mois peut devenir root.
Et quand j'étais admin sur le projet, j'avais fini par abandonner l'idée de sécuriser quoi que ce soit contre moi même au vue du manque de ressources chroniques. Et encore une fois, mon expérience montre que c'est globalement pareil partout (vu que j'ai fini par faire de l'admin pour projet libre mon activité professionnel, parce que j'estime qu'il vaut mieux bosser pour corriger un problème que de chouiner sur linuxfr, ce qui n'est pas le cas de tout le monde).
sinon, pas compris l’intérêt de l'anti-spam en lecture.
C'est une feature de base de sympa. Personne n'a envoyé de patch pour la retirer (sur sympa, ou sur le dépôt puppet de mageia), et j'ai déjà eu asse de mal à faire passer sympa dans puppet à l'époque.
J'ai appris ceci dit que le travail pour une nouvelle interface est en cours (cf https://listes.renater.fr/sympa/arc/sympa-fr/2017-04/msg00000.html ), donc à défaut d'envoyer du code (je ne me fait plus d'espoir), tu peux sans doute aller ouvrir un bug (et c'est en français, donc pas de souci avec la langue).
Le foutage de gueule c'est de venir parler de risque zéro quand son infra est toute trouée.
Venir agresser des bénévoles par le biais de LinuxFr, c'est pas terrible comme comportement. L'infrastructure de Mageia a le bon gout d'être ouverte depuis le début, et quand j’étais un des admins la bas, j'ai reçu epsilon patchs de la communauté. Soit, faire l'administration système, c'est compliqué et c'était pas vraiment une des compétences des utilisateurs dans la communauté. J'ai bien conscience que puppet (l'outil choisi à l'époque) est un outil non trivial pour le péquin moyen (voir même les concepts modernes de gestion de serveurs). Et si je devais le refaire maintenant, je referais ça autrement (et je le refait autrement justement).
Mais c'est pas le propos. Le propos, c'est que sans aide et sous la charge de travail (bénévole), j'ai quitté le projet pour éviter le burnout. Burnout qui a failli me couter mon taf à mi-temps et qui m'a couté la relation avec ma copine de l'époque. Je suis pas non plus le seul, car d'autres admins ont lachés l'équipe pour divers raisons (parfois de santé, parfois autres). Mais curieusement, y a pas grand monde qui est venu remplacer les départs depuis la communauté.
Donc arriver en donneur de leçon la bouche en cœur, c'est totalement contre productif et passablement odieux vu que ça va juste dégouter les gens de filer du travail gratuitement à des gens dont la gratitude semble inexistante.
Si quelqu'un estime pouvoir donner son avis sur le taf à faire par des bénévoles, y a plusieurs solutions. Soit la personne a les compétences et je m'attends à minimum de voir un patch arriver. Soit la personne n'a pas les compétences, et je m'attends à ce que les gens aient la décence de ne pas se comporter de façon hautaine à expliquer à ceux qui font le travail comment le faire en étant insultant.
Ou si la personne n'a pas le temps, je m'attends aussi à ce que les gens comprennent que le temps des autres aussi n'est pas infini.
Je ne veux pas minimiser les soucis d'attaques sur les infras, ça arrive en moyenne une fois tout les 3 mois d’après mes recherches (moyenne fait sur les 10 dernières années). Mais ce genre de soucis, c'est aussi arrivé à beaucoup de projets et pas des moindres :
J'ai une liste de 50 compromissions, je peux continuer toute la nuit.
Tantôt c'est du vol de compte. Tantôt c'est du bruteforce de login ssh. Parfois, on sait pas car personne n'a fait de forensic (parce que oui, la sécurité, c'est un métier, c'est pas juste aller crier sur les gens sur un site web, au cas ou les gens auraient des doutes).
Parfois les détails sont pas publiques, et j'ai eu beaucoup de mal à retrouver des infos. J'ai pas encore pu tomber sur des 0days de folies ou des exploits complexes, et pourtant j'ai fait le tour des confs pour parler aux gens impliqués dans certains cas, je me suis tapé facile 30 à 40 rapports sur les différentes attaques pour comprendre (https://github.com/aptnotes/data ).
Mais la cause à la base, c'est souvent toujours pareil. C'est des systèmes oubliés, mal sécurisés et souvent un manque d'admin sur des projets, parfois pendant plusieurs années. Des admins qui sont pas forcément formé sur les bonnes pratiques en cours, parce que ça reste quand même difficile à en trouver.
Donc si en plus, faut en trouver qui sont d'accord pour bosser gratuitement, en plus de l'activité normal et en plus se faire pourrir par des inconnus sur le web, c’est plus du recrutement, c'est une chasse au dahu.
Je pourrais aussi parler pendant des heures sur les mécanismes et dynamiques de récompenses autour du logiciel libre et comment le travail d'un admin passe à la trappe, vu que faire le travail correctement implique que ça soit invisible.
Mais ce commentaire est déjà trop long, donc je vais juste conclure pour dire que venir agresser les gens comme tu le fait, c'est aggraver le problème. Et c'est clairement une raison de plus de pas se bouger. De ne pas se bouger par épuisement aprés avoir fait souvent plus que la moyenne, et que ça soit pas suffisant. De ne pas se bouger à cause de l'ingratitude manifeste. De ne pas se bouger par le paternalisme du ton employé.
C'est facturé par cpu, et c'est libre. Va relire ce que dit le contrat de souscription, (si tu l'as lu, car je suppose que sinon, tu commencerais pas à m'affirmer ce qui est marquer dedans, ni à tenter de m'expliquer ce que vends mon employeur)
Tu dois parler de support (rien à voir avec le libre),
Non, je parle pas de support, sinon, j'aurais dit "support".
pas le livrable (qui et libre).
Je suppose que je dois lire "qui est libre".
Rien à voir, le résultat est libre pas par CPU (ils filent
même CentOS maintenant).
Sans vouloir trop pinailler, Centos est fourni par l'équipe Centos, pas par RH. Karanbir Singh (le fondateur) y tient beaucoup, et même si il est payé par RH (en tant qu'Architect dans une équipe d'outil pour dev), il veut que le projet reste séparé. L'infra est physiquement séparé dans des DC différents (sauf 1), et RH intervient pas dessus. La clé de signature est différente, les binaires sont différents, la taille des équipes est différente. L'équipe Centos chez RH est minuscule (5 personnes), et fait grosso modo la même chose qu'avant, à savoir recompiler RHEL.
Faire du support par CPU est une façon de faire rentrer le
fric, ça reste toutefois une façon de diviser le coût et pas
"je te facture le coût, mais en plus je te facture en plus
pour la diffusion".
Encore une fois, c'est pas du support, c'est une souscription qui donne accès aux binaires des mises à jours, avec du support en option (en option car tu as aussi des offres sans, et qui sont pas pour autant gratuite), à une assurance en cas de litige autour des brevets (exemple, RH a suivi Rackspace en 2013 sur le sujet exactement à cause de ça) et divers trucs qu'un commercial bien au courant doit pouvoir t'expliquer (genre les certifications logiciels, qui doivent sans doute pas t'intéresser, mais qui visiblement importe pas mal à des clients).
Quand au cout de diffusion, il est facturé dans tout les cas, sauf à croire que la bande passante, les serveurs et tout ça sont gratuit (et on peut compter aussi le coût des commerciaux, des jursites pour la rédaction des contrats, des comptables, les frais bancaires). C'est juste suffisamment faible et industrialisé pour que ça soit oubliable.
Je n'ai pas créé les règles du libre, et le libre interdit de
limiter la diffusion (par CPU, par support…) par définition.
Pourquoi vouloir centrer sur moi quand ça ne te plait pas?
Parce que tu as un ton péremptoire et que tu dis des choses fausses. Et tu continues.
Par exemple, juste la. Si tu regardes quelques licences libres, t va voir que "le libre interdit de limiter la diffusion" est une simplification trompeuse (et ça, c'est en dehors du fait que tu précises pas de quoi ça interdit de limiter la diffusion). À part une paire plus proches du domaine publique ou équivalent, elles vont toutes limiter la diffusion si tu ne remplis pas certaines conditions. Exemple, la MIT te donne le droit de distribuer sous condition, et si tu remplis pas les conditions, alors tu perds le droit de distribuer.
Il y a aussi un gros flou juridique qui fait que tu va pas pouvoir mélanger du code et le diffuser n'importe comment. E.g si je prends du code sous une licence GPL avec du code sous une licence non compatible (CDDL), et que je le compile pour moi, ça semble passer mais je suis pas sur d'avoir le droit de distribuer les binaires (cf zfs, canonical, etc).
Donc ouais, les règles du libre, c'est bien joli, mais la CDDL et la GPL sont libres, la MIT est libre, et pourtant, mes 2 exemples montre bien que la simplification tient pas la route.
Et c'est aussi oublier que le droit du copyright et des marques déposés s'applique aussi, de manière transverse à la notion de code libre.
Maintenir 2 interfaces, ç'est un cout loin d'être négligeable. Il y a tout un travail de QA à faire en double, écrire plus de documentation, diviser les gens qui font du support sur les listes, etc.
Donc sauf si il y a assez de gens qui sont la pour absorber ce coût en donnant du temps libre et/ou du pognon, je suis pas sur que ça arrive.
Red Hat ne facture pas de la réalisation mais du support (même
si les deux sont liés).
D'une part, il a a plus que le support, il y a les certifications avec les partenaires, la maintenance. D'autre part, la facturation à la réalisation, ça s'appelle du consulting aussi. Et bien que RH ne fasse pas trop de développement à façon (en dehors des scripts pondus par les consultants), d'autres boites le font (exemple, Canonical a eu ça comme offre pour les partenaires OEM)
Comment tu fais du support avec le design ? C'est plutôt du one
shot, avec des corrections par moment peut être mais tu factures > par pallier pour la réalisation.
Ça dépend du design de quoi. Un site web, ça se rafraichit de temps par exemple.
Le souci aussi, c'est que tu n'entends les gens que quand ça leur plait pas. Tu entends ni les nouveaux utilisateurs à qui ça plait, ni les anciens à qui ça plait. Tu vois pas si il y a eu moins d'appels au support, si les tests ont montrés que c'était plus facile, si les gens ont plus rapidement compris.
En gros, on parle que des problèmes, jamais des améliorations. C'est comme conclure qu'un logiciel est vachement bugué parce qu'il y a plein de bugs ouverts, c'est pas regarder la bonne métrique.
je ne connais personnellement aucun exemple de tel logiciel.
Gnuradio compagnon me semble coller avec ce que tu dis. (ironie, il est la justement parce que le texte ne suffit pas pour traiter du binaire)
les autres sont vraiment des daubes en matière d'ergonomie ou de
productivité.
Alors autant pour le libre que pour le proprio, je pense qu'il faut arrêter de balancer sans justifier "c'est des daubes". Sans savoir ce que tu veux faire avec le logiciel, ni comment le logiciel te bloque ou comment il réduit ta productivité, ç'est une opinion qui n'apporte pas grand chose et qui a plus tendance à démoraliser et à démotiver.
Et autant, je doute que grand monde de Google te lise et corrige Gmail (pour ne citer que lui), autant je pense que prendre les bonnes habitudes va permettre justement d'avoir plus de chances d'attirer des designers.
On est ici dans l'opposition complète au libre, qui ne
s’intéresse pas à la diffusion (combien, support etc)
Tu généralises par rapport à ta situation, mais y a pas que des PMEs et des petites boites dans le libre. Dans la pratique, les boites plus grosse (et qui marche, genre Red Hat, ou Suse) facture pas le libre "à la réalisation", mais bien à l'usage par processeur.
Donc bon, l'opposition au libre, faudra repasser, sauf à vouloir dire "l'opposition au libre suivant Zenitram", ce qui est une assez grosse nuance.
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
En gros, oui, le libre est la ou y a pas d'interface. L'exception dans ta liste, c'est dotclear. Mais sinon, l'interface de la box ADSL est sans doute non libre, la majorité du code qui tourne par dessus linux est non libre (que ça soit sur les serveurs webs, ou sur un tel android).
Donc ouais, cool, le libre a permis au propriétaire de monter d'un cran.
Mais dans le cas de Twitter (que j'utilise pas, mais que je vais lire à la mano), j'aurais tendance à dire que l'ergonomie et l'UX marchent comme on leur demande de marcher, avec "on" étant "les patrons de Twitter". Pas "on" étant les utilisateurs de la plateforme. Et c'est le nœud du problème.
Twitter, comme beaucoup de réseau sociaux, a une interface dont le but est de retenir les gens sur la plateforme, et de rendre les choses virales (par design). Les raisons pour ça sont assez claires (utilisateurs qui passent du temps => afficher des pubs => argent => payer les employés/la piscine du CEO).
Et on voit que par exemple, comme la protection des utilisateurs n'est pas une priorité (en partie parce que ça réduit l'usage de la plateforme, en partie parce que les créateurs de Twitter n'ont pas du subir de soucis assez souvent pour que ça leur vienne à l'idée que ça arrive aux autres), alors l'interface est naze pour ça, malgré des propositions concrètes comme https://artplusmarketing.com/putting-out-the-twitter-trashfire-3ac6cb1af3e?source=user_profile---------1----------
L'UX du web de nos jours utilise fortement les méthodes tel que l'A/B testing pour vérifier les hypothèses (voir https://www.behave.org/tests-of-the-week/ pour des tas d'exemple instructifs). Donc si quelqu'un dit à l'équipe en charge du design "qu'est ce qu'on peut faire pour que les gens passent plus de temps sur le site", alors quelqu'un va trouver et mettre l'interface pour ça.
Et donc, oui, l'interface de Twitter est bien faite, mais pour ses propriétaires, avec ce qu'ils veulent en faire. Pas pour ses utilisateurs, avec ce qu'ils veulent en faire.
Et c'est la ou le logiciel libre a une carte à jouer, en proposant des interfaces qui vont aller beaucoup plus dans le sens de l'utilisateur, tout comme un logiciel libre va aller beaucoup plus dans le sens du respect de la vie privée de son utilisateur que dans le sens inverse.
[^] # Re: on vit une époque formidable
Posté par Misc (site web personnel) . En réponse au journal Comment bloquer 280M de dollars en éther . Évalué à 3.
Merci pour l'explication.
J'ajouterais qu'il existe un outil pour vérifier ça:
https://github.com/b-mueller/mythril
[^] # Re: on vit une époque formidable
Posté par Misc (site web personnel) . En réponse au journal Comment bloquer 280M de dollars en éther . Évalué à 3. Dernière modification le 09 novembre 2017 à 11:12.
Ce qui en soit est pas si différent du type de déploiement qu'on voit pour de l'embarqu
^WIOT. Et dire qu'on peut pas mettre à jour, c'est aussi un peu trompeur. Tu pourrais si tu avais le controle de la blockchain entiére. C'est certes sans doute impossible pour une blockchain publique, mais je suis sur qu'il existe des applications ou tu as ta propre blockchain privé et ou c'est faisable, ce qui limite quand même les risques (un peu comme faire un git push -f, ça passe mieux quand tu es seul)[^] # Re: ça manque de données
Posté par Misc (site web personnel) . En réponse au journal FAI associatif / FDN / Hébergement et stockage. Évalué à 2.
Le RAID, j'ai pas tendance à voir ça comme une sécurité des données plus que s'assurer de la disponibilité et que l'uptime ne prends pas un coup si un disque tombe (en partant du principe que tu as un niveau de raid différent de 0). Parce que le RAID sécurise pas vraiment contre un effaçage par erreur ou contre un bug du FS :/
En fait, j'ai vraiment tendance à ne pas aimer qu'on parle de sécurisation sans dire "contre quoi", parce que ç'est indispensable pour savoir ce qui manque, surtout si c'est à destination des membres, qui vont pas forcément avoir le réflexe de penser "ok, qu'est ce qui se passe si tel truc arrive".
Plus simple oui, mais je suis pas sur que ça marche à 100%. Encore une fois, tu peux avoir le disque dans un état non consistant. Et ça, c'est quand tu as pas des données sur plusieurs disques (exemple, un serveur sql partagé et X serveurs webs avec des applis différentes), parce que ça devient vite compliqué Ensuite, je donne le pire cas possible, il est possible que ça marche suffisamment bien et que tu puisses corriger à la main le reste du temps (e.g, aller tripoter dans la DB si besoin), donc je suppose qu'il ne faut pas faire une usine à gaz.
[^] # Re: Glusterfs / Proxmox
Posté par Misc (site web personnel) . En réponse au journal FAI associatif / FDN / Hébergement et stockage. Évalué à 2.
7 serveurs physiques, ça me parait un chouia trop. Tu peux t'en sortir avec moins si tu mets les OSD et les moniteurs sur les mêmes machines, en partant du principe que tu as dimensionné ça de façon à ce que ça passe (genre, avoir un disque, asse de ram et un CPU par OSD, et donc un CPU et assez de ram pour le moniteur, avec "assez" documenté sur ceph.com).
Ensuite, ça dépend aussi de la topologie réseau que tu va mettre des patterns d'accès, de la volumétrie, des perfs que tu veux avoir.
[^] # Re: Glusterfs / Proxmox
Posté par Misc (site web personnel) . En réponse au journal FAI associatif / FDN / Hébergement et stockage. Évalué à 2.
Il suffit de répliquer les images de VM stocké sur le disque.
# ça manque de données
Posté par Misc (site web personnel) . En réponse au journal FAI associatif / FDN / Hébergement et stockage. Évalué à 4.
Le draft manque AMHA d'info.
Par exemple, ça parle de réplication, mais est ce que l'idée est d'avoir une réplication en temps réel (et donc synchrone) auquel cas les performances vont chuter si tu fait ça sur un site distant, ou d'avoir des trucs asynchrones et de la magie pour revenir quand ça explose ?
Il n'y a pas spécialement de discussion sur la volumétrie non plus ou la question du lien entre les sites.
Le type de données va aussi importer. L'utilisation de GlusterFS pour stocker des images de VM fait parti des cas supportés par le projet (vu que c'est des gros fichiers, ç'est assez performant), et le projet ovirt le supporte. Mais de la même façon, des gens placent le stockage en mode bloc dans Ceph.
Mais si le but est d'avoir des machines dont tu fait des snapshot, je pense que tu peux pas éviter d'aller dans la VM et faire des choses pour que les données sur le disque soit cohérentes.
J'ai par exemple du mal à voir comment une synchro des blocs ne va pas corrompre une base de données et une appli web si ça pête au mauvais moment, vu que c'est rarement atomique (sauf à tout mettre dans la base de données, et à avoir des transactions, mais je pense que pas grand monde vérifie ça, et qu'à choisir entre une appli qui va exploser sous un cas critique, et pas d'appli, les gens prennent l'appli quand même).
Du coup, si tu fait la redondance au niveau au dessus, tu as moins besoin au niveau en dessous.
Donc les besoins vont dépendre des applis. Est ce qu'il faut avoir de la HA automatique, ou remonter rapidement suffit ? Comment le systéme va devoir se débrouillé en mode dégradé ?
Pour reprendre l'appli d'exemple de toute à l'heure, une solution de stockage classique avec une base SQL répliqué suffirait, avec des frontends sans état, pas besoin de sortir des trucs complexes (pour peu que les VMs soit identiques)
Et sinon, on est en 2017, les archis à base de conteneurs ont le vent en poupe, et ont le bon gout de pousser à séparer données et codes, ce qui permet aussi de se focaliser sur ce qui AMHA importe, les données. Je dit pas que c'est une bonne idée, mais je pense que c'est pas déconnant de regarder. Et pas regarder docker tout nu, plus des choses comme kubernetes/openshift ou mesos, avec idéalement une stack supporté.
Et la partie "pas de java" me parait quand même restrictive et sans doute mal exprimé. Parce que je suis sur que pour certaines choses, y a sans doute d'autres languages qui vont faire pire que java (cough golang et rust pour du statique, ruby pour tirer 5T de deps), donc je suis sur qu'il y a plus précis comme demande.
# Des goodies tout fait
Posté par Misc (site web personnel) . En réponse à la dépêche Updates-warner : pour être alerté d’une modification de ressource Web. Évalué à 6.
Je sais déjà ce que tu peux offrir comme goodies:
Des brosses, pour dire "c'est une updates-warner brosse".
[^] # Re: A ceux qui critiquent....
Posté par Misc (site web personnel) . En réponse au journal Pas de mises à jour de sécurité depuis 5 ans sur l’infrastructure Mageia. Est‐ce bien raisonnable ?. Évalué à 10.
Arrête ton char, tu sais très bien que dans l'IT, tu as toujours un delta énorme entre ce que tu voudrais faire, et ce que tu peux faire dans les temps.
Et la, c'est pareil, sauf qu'en plus, tu as moins de monde et de temps.
Vous bossez dans quel boite pour que tout les serveurs soient tous sur la dernière version, pour ne pas avoir des tonnes d'autres trucs à faire ?
Parce que les clients dont j'entends parler, c'est migration à RHEL 7 2 ou 3 ans après la release, parfois certains envisagent passer à RHEL 6. C'est des serveurs encore en 12.04 ou 10.04 que les gens peuvent pas migrer rapidement, parce que tout à changer et y a pas de budget.
Y a aucun des admins qui est sur le projet à temps plein, et pire encore, aucun qui est uniquement contributeur à l'admin de l'infra.
Et même au delà de ça, tu regardes quand Gitlab a eu un gros souci, des gens ont dit "ça arrive à tous" (sur twitter) et ça a globalement été positif. Ici, c'est juste du fiel et du purin sur des bénévoles en sous effectif à cause du stress, pour un souci qui n'a pas eu lieu.
Mais c'est quoi comme ambiance de merde dans ce coin du logiciel libre ?
[^] # Re: Et ils continuent de nier le problème ...
Posté par Misc (site web personnel) . En réponse au journal Pas de mises à jour de sécurité depuis 5 ans sur l’infrastructure Mageia. Est‐ce bien raisonnable ?. Évalué à 4.
Au passage, pour avoir regarder le fonctionnement des dits bots qui se baladent (c'est pas dur, tu peux juste mettre un pauvre honeypot ssh, y en a des tonnes et c'est facile d'en écrire un avec twisted), la majorité des bots vont tentés d'exploiter des failles archi courantes.
Soit des mots de passes par défaut et/ou faibles (cas des bots ssh, genre mirai), soit des failles connus dans des softs classiques (style wordpress), soit shellshock.
Que je sache, rien de tout ça ne s'applique à ce serveur:
- c’était du mod_perl, on évite globalement shellshock via mod_cgi
- pas de wordpress dessus (que je me souvienne)
- le ssh est par clé uniquement dans mon souvenir
Donc sauf erreur de ma part et sur la base des bots que je voit sur mes serveurs, le risque est globalement faible.
Ensuite, tu as peut être sans doute d'autres infos qui te permettent d'être plus affirmatif que moi, auquel cas je suis sur que tu peux les partager pour faire avancer le débat de façon constructive.
[^] # Re: A ceux qui critiquent....
Posté par Misc (site web personnel) . En réponse au journal Pas de mises à jour de sécurité depuis 5 ans sur l’infrastructure Mageia. Est‐ce bien raisonnable ?. Évalué à 10.
C'est assez hautain et puant comme commentaire, j'aurais honte de parler sans savoir à ta place.
L'équipe d'admin sys de Mageia au début, ç'était 10 personnes. Sur les 10, je compte 7 admins de profession (2 dans une université, 1 chez un telco, 2 dans 2 multinationals du secteur informatique bien connus).
Donc non, je pense pas qu'on est face à n'importe qui.
C'est pas le manque de compétence. C'est le manque de temps et de personne, vu qu'au fur et à mesure des années, 3 (ou plus) ont eu des gamins, 3 sont parti en burnout et/ou depressions (parfois pas à cause du projet) et parfois revenus, 3 ont changés de taf (et on arrêté le projet). Et comme tu dis, l'admin sys, c'est un métier, et personne n'est venu faire un métier gratuitement sur son temps libre pour aider (chose plus dur qu'être désobligeant envers les autres, je le conçoit).
[^] # Re: Et ils continuent de nier le problème ...
Posté par Misc (site web personnel) . En réponse au journal Pas de mises à jour de sécurité depuis 5 ans sur l’infrastructure Mageia. Est‐ce bien raisonnable ?. Évalué à 9.
S’arrêter de faire quoi ?
S’arrêter de filer du temps gratos ?
S'arrêter de faire le travail en risquant de se faire insulter sur linuxfr ? Qu'est qui aurait du être arrêter ?
Ça se voit quand même que tu as jamais bossé dans un projet d'envergure avec du monde, voir même fait de la gestion de risque. Deja, tu va pas dire "on ferme le projet, on a un serveur pas à jour", surtout quand, comme dit par Pascal, un plan pour la mise à jour est en cours. Peut être qu'envoyer chier le monde est trivial pour toi, mais c'est pas le cas de tout le monde. Donc oui, les gens vont pas arrêter quand il est trop tard, et surtout pour Mageia (j'ai pas besoin de parler de l'histoire de la distribution).
De surcroit, c'est quand "trop tard" ? Y a pas de moment exact pour ça
Ça a toujours été publique pour qui sait regarder. Et encore une fois, l'attente que les bénévoles doivent réagir dans l'heure et rapidement est une source de stress. Et le stress et le burnout dans le libre est un souci.
Mais le souci est pas de signaler un problème.
Le souci, c'est de signaler un problème connu depuis longtemps et de croire qu'aller insulter les gens pour forcer la migration va aider.
Coquelicot-bleu a bien dit qu'ielle utilise pas la distribution, donc ielle n'a même pas l'excuse de faire ça pour son propre bénéfice. Les admins étaient déjà au courant. Il ne faut pas non plus prendre la profession pour des idiots, on sait exactement ce qui est pas à jour, on sait ce qui est risqué, la dette technique, on a ça en tête tout les jours.
Donc ce que ça va donner, c'est une migration potentiellement rushé, des attaques sur Linuxfr sur les gens qui font le travail, et sans doute un pas de plus vers le burn out pour eux.
Tout ça pour une attaque qui n'a pas eu lieu, pour un serveur qui n'est pas si critique que ce qu'il veut faire croire (et moi, je sais comment est architecturer le système, je sais ou sont les points faibles qu'on a pas pu renforcer de mon temps, vu que j'ai été un de ces architectes). Oui, ça aurait du être mis à jour plus tôt, mais "c'est la vie", surtout si les bénévoles sont pas des esclaves (parce que bon, dire "faut faire ça, et fait ça gratos et plus vite", ç'est quand même une forme de pression psychologique assez mauvaise).
[^] # Re: Tu ne sais pas
Posté par Misc (site web personnel) . En réponse au journal Pas de mises à jour de sécurité depuis 5 ans sur l’infrastructure Mageia. Est‐ce bien raisonnable ?. Évalué à 10.
Le serveur est juste un client ldap élaboré. Donc si jamais tu prends le contrôle du dit serveur, tu va pas avoir plus de contrôle que si tu attaques le ldap directement. Tu va avoir en effet une vue sur ce qui se passe, mais c'est autre chose.
Puppet va reverter le changement (déploiement auto depuis git/svn), et/ou le signaler. Tu devrais pas faire tes attaques au hasard, ça a pas l'air de marcher dans la vraie vie.
Puppet va reverter le changement, et/ou le signaler (c'est le but de puppet).
Bien sur, tu peux couper puppet, mais dans ce cas, ça va lancer une alerte assez vite sur le monitoring pour dire que "tel client n'a plus puppet qui tourne"
Donc la fenêtre de tir est assez courte (grosso modo, puppet se lance toutes les heures), il faut que tu fasses une attaque et que dans l'heure, un des 5 ou 6 admins se connecte pour changer sa clé sur l'interface (et pas ldapvi).
Ou que tu attaques de façon plus spécifique pour pas te faire choper (ce qui est faisable, même si j'ai plus les détails en tête, j'ai tenté de fermer ça autant que possible).
Je ne dit pas que c'est impossible, mais on sort très clairement des attaques de script kiddies. De mon expérience (ie, à dealer avec des vraies attaques et à faire du forensic), puppet est déjà au delà des capacités des admins moyens (sinon, je pense qu'il y aurait eu plus de patch), et donc du script kiddie moyen. J'ai eu à dealer avec des serveurs compromis, et en général, la ligne de commande classique est souvent déjà au delà des capacités de l'attaquant lambda, comme n'importe qui qui a pu lire un .bash_history d'un serveur compromis ou d'un honeypot a pu le constater.
Soit tu tombes sur des gens motivés et avec des ressources, et c'est globalement foutu si tu as pas autant de ressources en face (une équipe legere d'attaquant, ça se chiffre dans les 2 millions par an, cf https://medium.com/@thegrugq/cyber-ignore-the-penetration-testers-900e76a49500 ). Soit tu va tomber sur des attaquants moins staffés, et en général, c'est des boulets qui vont faire du bruteforce classique. Il y a fort peu de cas entre les 2 (ou personne n'en parle, mais c'est un autre débat).
Donc si le but est de rajouter une backdoor, c'est infiniment plus sur et plus rapide de juste devenir packageur et de rajouter ça dans la distribution. Genre en changeant un tarball d'un soft utilisé partout mais pas signé (y en a un paquet). Ça ne serait pas pérenne, mais sans doute discret.
Ou voir même, de devenir admin. Il y a tellement besoin d'aide que je suis sur qu'une personne en 2 mois peut devenir root.
Et quand j'étais admin sur le projet, j'avais fini par abandonner l'idée de sécuriser quoi que ce soit contre moi même au vue du manque de ressources chroniques. Et encore une fois, mon expérience montre que c'est globalement pareil partout (vu que j'ai fini par faire de l'admin pour projet libre mon activité professionnel, parce que j'estime qu'il vaut mieux bosser pour corriger un problème que de chouiner sur linuxfr, ce qui n'est pas le cas de tout le monde).
[^] # Re: Ha, ouais.
Posté par Misc (site web personnel) . En réponse au journal Pas de mises à jour de sécurité depuis 5 ans sur l’infrastructure Mageia. Est‐ce bien raisonnable ?. Évalué à 6.
C'est une feature de base de sympa. Personne n'a envoyé de patch pour la retirer (sur sympa, ou sur le dépôt puppet de mageia), et j'ai déjà eu asse de mal à faire passer sympa dans puppet à l'époque.
J'ai appris ceci dit que le travail pour une nouvelle interface est en cours (cf https://listes.renater.fr/sympa/arc/sympa-fr/2017-04/msg00000.html ), donc à défaut d'envoyer du code (je ne me fait plus d'espoir), tu peux sans doute aller ouvrir un bug (et c'est en français, donc pas de souci avec la langue).
[^] # Re: Et ils continuent de nier le problème ...
Posté par Misc (site web personnel) . En réponse au journal Pas de mises à jour de sécurité depuis 5 ans sur l’infrastructure Mageia. Est‐ce bien raisonnable ?. Évalué à 5.
Surtout pour un compte ouvert hier juste pour poster ça.
[^] # Re: Et ils continuent de nier le problème ...
Posté par Misc (site web personnel) . En réponse au journal Pas de mises à jour de sécurité depuis 5 ans sur l’infrastructure Mageia. Est‐ce bien raisonnable ?. Évalué à 10.
Euh non, ça va être corrigé grâce aux gens qui font le taf.
Encore une fois, on se retrouve à masquer le travail des admins, faut pas s'étonner que les gens se découragent.
[^] # Re: Et ils continuent de nier le problème ...
Posté par Misc (site web personnel) . En réponse au journal Pas de mises à jour de sécurité depuis 5 ans sur l’infrastructure Mageia. Est‐ce bien raisonnable ?. Évalué à 10.
Venir agresser des bénévoles par le biais de LinuxFr, c'est pas terrible comme comportement. L'infrastructure de Mageia a le bon gout d'être ouverte depuis le début, et quand j’étais un des admins la bas, j'ai reçu epsilon patchs de la communauté. Soit, faire l'administration système, c'est compliqué et c'était pas vraiment une des compétences des utilisateurs dans la communauté. J'ai bien conscience que puppet (l'outil choisi à l'époque) est un outil non trivial pour le péquin moyen (voir même les concepts modernes de gestion de serveurs). Et si je devais le refaire maintenant, je referais ça autrement (et je le refait autrement justement).
Mais c'est pas le propos. Le propos, c'est que sans aide et sous la charge de travail (bénévole), j'ai quitté le projet pour éviter le burnout. Burnout qui a failli me couter mon taf à mi-temps et qui m'a couté la relation avec ma copine de l'époque. Je suis pas non plus le seul, car d'autres admins ont lachés l'équipe pour divers raisons (parfois de santé, parfois autres). Mais curieusement, y a pas grand monde qui est venu remplacer les départs depuis la communauté.
Donc arriver en donneur de leçon la bouche en cœur, c'est totalement contre productif et passablement odieux vu que ça va juste dégouter les gens de filer du travail gratuitement à des gens dont la gratitude semble inexistante.
Si quelqu'un estime pouvoir donner son avis sur le taf à faire par des bénévoles, y a plusieurs solutions. Soit la personne a les compétences et je m'attends à minimum de voir un patch arriver. Soit la personne n'a pas les compétences, et je m'attends à ce que les gens aient la décence de ne pas se comporter de façon hautaine à expliquer à ceux qui font le travail comment le faire en étant insultant.
Ou si la personne n'a pas le temps, je m'attends aussi à ce que les gens comprennent que le temps des autres aussi n'est pas infini.
Je ne veux pas minimiser les soucis d'attaques sur les infras, ça arrive en moyenne une fois tout les 3 mois d’après mes recherches (moyenne fait sur les 10 dernières années). Mais ce genre de soucis, c'est aussi arrivé à beaucoup de projets et pas des moindres :
Php.net, 2013: https://barracudalabs.com/2013/10/php-net-compromise/
Rubygem: http://blog.rubygems.org/2013/01/31/data-verification.html
Ou des distros/OS:
Debian: https://lwn.net/Articles/191744/
https://www.debian.org/devel/debian-installer/News/2003/3
FreeBSD (2012):
https://www.freebsd.org/news/2012-compromise.html
Red Hat/Fedora (2008):
https://www.cnet.com/news/red-hat-fedora-servers-compromised/
J'ai une liste de 50 compromissions, je peux continuer toute la nuit.
Tantôt c'est du vol de compte. Tantôt c'est du bruteforce de login ssh. Parfois, on sait pas car personne n'a fait de forensic (parce que oui, la sécurité, c'est un métier, c'est pas juste aller crier sur les gens sur un site web, au cas ou les gens auraient des doutes).
Parfois les détails sont pas publiques, et j'ai eu beaucoup de mal à retrouver des infos. J'ai pas encore pu tomber sur des 0days de folies ou des exploits complexes, et pourtant j'ai fait le tour des confs pour parler aux gens impliqués dans certains cas, je me suis tapé facile 30 à 40 rapports sur les différentes attaques pour comprendre (https://github.com/aptnotes/data ).
Mais la cause à la base, c'est souvent toujours pareil. C'est des systèmes oubliés, mal sécurisés et souvent un manque d'admin sur des projets, parfois pendant plusieurs années. Des admins qui sont pas forcément formé sur les bonnes pratiques en cours, parce que ça reste quand même difficile à en trouver.
Donc si en plus, faut en trouver qui sont d'accord pour bosser gratuitement, en plus de l'activité normal et en plus se faire pourrir par des inconnus sur le web, c’est plus du recrutement, c'est une chasse au dahu.
Je pourrais aussi parler pendant des heures sur les mécanismes et dynamiques de récompenses autour du logiciel libre et comment le travail d'un admin passe à la trappe, vu que faire le travail correctement implique que ça soit invisible.
Mais ce commentaire est déjà trop long, donc je vais juste conclure pour dire que venir agresser les gens comme tu le fait, c'est aggraver le problème. Et c'est clairement une raison de plus de pas se bouger. De ne pas se bouger par épuisement aprés avoir fait souvent plus que la moyenne, et que ça soit pas suffisant. De ne pas se bouger à cause de l'ingratitude manifeste. De ne pas se bouger par le paternalisme du ton employé.
[^] # Re: Pour savoir où on met les pieds
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 2.
C'est facturé par cpu, et c'est libre. Va relire ce que dit le contrat de souscription, (si tu l'as lu, car je suppose que sinon, tu commencerais pas à m'affirmer ce qui est marquer dedans, ni à tenter de m'expliquer ce que vends mon employeur)
Non, je parle pas de support, sinon, j'aurais dit "support".
Je suppose que je dois lire "qui est libre".
Sans vouloir trop pinailler, Centos est fourni par l'équipe Centos, pas par RH. Karanbir Singh (le fondateur) y tient beaucoup, et même si il est payé par RH (en tant qu'Architect dans une équipe d'outil pour dev), il veut que le projet reste séparé. L'infra est physiquement séparé dans des DC différents (sauf 1), et RH intervient pas dessus. La clé de signature est différente, les binaires sont différents, la taille des équipes est différente. L'équipe Centos chez RH est minuscule (5 personnes), et fait grosso modo la même chose qu'avant, à savoir recompiler RHEL.
Encore une fois, c'est pas du support, c'est une souscription qui donne accès aux binaires des mises à jours, avec du support en option (en option car tu as aussi des offres sans, et qui sont pas pour autant gratuite), à une assurance en cas de litige autour des brevets (exemple, RH a suivi Rackspace en 2013 sur le sujet exactement à cause de ça) et divers trucs qu'un commercial bien au courant doit pouvoir t'expliquer (genre les certifications logiciels, qui doivent sans doute pas t'intéresser, mais qui visiblement importe pas mal à des clients).
Quand au cout de diffusion, il est facturé dans tout les cas, sauf à croire que la bande passante, les serveurs et tout ça sont gratuit (et on peut compter aussi le coût des commerciaux, des jursites pour la rédaction des contrats, des comptables, les frais bancaires). C'est juste suffisamment faible et industrialisé pour que ça soit oubliable.
Parce que tu as un ton péremptoire et que tu dis des choses fausses. Et tu continues.
Par exemple, juste la. Si tu regardes quelques licences libres, t va voir que "le libre interdit de limiter la diffusion" est une simplification trompeuse (et ça, c'est en dehors du fait que tu précises pas de quoi ça interdit de limiter la diffusion). À part une paire plus proches du domaine publique ou équivalent, elles vont toutes limiter la diffusion si tu ne remplis pas certaines conditions. Exemple, la MIT te donne le droit de distribuer sous condition, et si tu remplis pas les conditions, alors tu perds le droit de distribuer.
Il y a aussi un gros flou juridique qui fait que tu va pas pouvoir mélanger du code et le diffuser n'importe comment. E.g si je prends du code sous une licence GPL avec du code sous une licence non compatible (CDDL), et que je le compile pour moi, ça semble passer mais je suis pas sur d'avoir le droit de distribuer les binaires (cf zfs, canonical, etc).
Donc ouais, les règles du libre, c'est bien joli, mais la CDDL et la GPL sont libres, la MIT est libre, et pourtant, mes 2 exemples montre bien que la simplification tient pas la route.
Et c'est aussi oublier que le droit du copyright et des marques déposés s'applique aussi, de manière transverse à la notion de code libre.
[^] # Re: Raisonnement débile ...
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 4.
Maintenir 2 interfaces, ç'est un cout loin d'être négligeable. Il y a tout un travail de QA à faire en double, écrire plus de documentation, diviser les gens qui font du support sur les listes, etc.
Donc sauf si il y a assez de gens qui sont la pour absorber ce coût en donnant du temps libre et/ou du pognon, je suis pas sur que ça arrive.
[^] # Re: Pour savoir où on met les pieds
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 4.
D'une part, il a a plus que le support, il y a les certifications avec les partenaires, la maintenance. D'autre part, la facturation à la réalisation, ça s'appelle du consulting aussi. Et bien que RH ne fasse pas trop de développement à façon (en dehors des scripts pondus par les consultants), d'autres boites le font (exemple, Canonical a eu ça comme offre pour les partenaires OEM)
Ça dépend du design de quoi. Un site web, ça se rafraichit de temps par exemple.
[^] # Re: Mon positionnement
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 4.
Dans le même genre d'idée, en 2002, je pense que mon pc avait déjà 256 de ram (donc 24 en 2001, c’était déjà un pc vieux de 5 ans)
[^] # Re: Raisonnement débile ...
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 6.
Le souci aussi, c'est que tu n'entends les gens que quand ça leur plait pas. Tu entends ni les nouveaux utilisateurs à qui ça plait, ni les anciens à qui ça plait. Tu vois pas si il y a eu moins d'appels au support, si les tests ont montrés que c'était plus facile, si les gens ont plus rapidement compris.
En gros, on parle que des problèmes, jamais des améliorations. C'est comme conclure qu'un logiciel est vachement bugué parce qu'il y a plein de bugs ouverts, c'est pas regarder la bonne métrique.
[^] # Re: Exemple de réponse
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 4.
Gnuradio compagnon me semble coller avec ce que tu dis. (ironie, il est la justement parce que le texte ne suffit pas pour traiter du binaire)
Alors autant pour le libre que pour le proprio, je pense qu'il faut arrêter de balancer sans justifier "c'est des daubes". Sans savoir ce que tu veux faire avec le logiciel, ni comment le logiciel te bloque ou comment il réduit ta productivité, ç'est une opinion qui n'apporte pas grand chose et qui a plus tendance à démoraliser et à démotiver.
Et autant, je doute que grand monde de Google te lise et corrige Gmail (pour ne citer que lui), autant je pense que prendre les bonnes habitudes va permettre justement d'avoir plus de chances d'attirer des designers.
[^] # Re: Pour savoir où on met les pieds
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 3.
Tu généralises par rapport à ta situation, mais y a pas que des PMEs et des petites boites dans le libre. Dans la pratique, les boites plus grosse (et qui marche, genre Red Hat, ou Suse) facture pas le libre "à la réalisation", mais bien à l'usage par processeur.
Donc bon, l'opposition au libre, faudra repasser, sauf à vouloir dire "l'opposition au libre suivant Zenitram", ce qui est une assez grosse nuance.
[^] # Re: C'est pas qu'une histoire d'ergo
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 7.
En gros, oui, le libre est la ou y a pas d'interface. L'exception dans ta liste, c'est dotclear. Mais sinon, l'interface de la box ADSL est sans doute non libre, la majorité du code qui tourne par dessus linux est non libre (que ça soit sur les serveurs webs, ou sur un tel android).
Donc ouais, cool, le libre a permis au propriétaire de monter d'un cran.
[^] # Re: .
Posté par Misc (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 10.
J'utilise pas Netflix, donc je ne peux pas juger.
Mais dans le cas de Twitter (que j'utilise pas, mais que je vais lire à la mano), j'aurais tendance à dire que l'ergonomie et l'UX marchent comme on leur demande de marcher, avec "on" étant "les patrons de Twitter". Pas "on" étant les utilisateurs de la plateforme. Et c'est le nœud du problème.
Twitter, comme beaucoup de réseau sociaux, a une interface dont le but est de retenir les gens sur la plateforme, et de rendre les choses virales (par design). Les raisons pour ça sont assez claires (utilisateurs qui passent du temps => afficher des pubs => argent => payer les employés/la piscine du CEO).
Et on voit que par exemple, comme la protection des utilisateurs n'est pas une priorité (en partie parce que ça réduit l'usage de la plateforme, en partie parce que les créateurs de Twitter n'ont pas du subir de soucis assez souvent pour que ça leur vienne à l'idée que ça arrive aux autres), alors l'interface est naze pour ça, malgré des propositions concrètes comme https://artplusmarketing.com/putting-out-the-twitter-trashfire-3ac6cb1af3e?source=user_profile---------1----------
L'UX du web de nos jours utilise fortement les méthodes tel que l'A/B testing pour vérifier les hypothèses (voir https://www.behave.org/tests-of-the-week/ pour des tas d'exemple instructifs). Donc si quelqu'un dit à l'équipe en charge du design "qu'est ce qu'on peut faire pour que les gens passent plus de temps sur le site", alors quelqu'un va trouver et mettre l'interface pour ça.
Un article qui a fait beaucoup de bruit à ce sujet l'année dernière explique mieux que moi le souci:
https://medium.com/swlh/how-technology-hijacks-peoples-minds-from-a-magician-and-google-s-design-ethicist-56d62ef5edf3#.yatff74k1
Et donc, oui, l'interface de Twitter est bien faite, mais pour ses propriétaires, avec ce qu'ils veulent en faire. Pas pour ses utilisateurs, avec ce qu'ils veulent en faire.
Et c'est la ou le logiciel libre a une carte à jouer, en proposant des interfaces qui vont aller beaucoup plus dans le sens de l'utilisateur, tout comme un logiciel libre va aller beaucoup plus dans le sens du respect de la vie privée de son utilisateur que dans le sens inverse.