Misc a écrit 6610 commentaires

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)

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.

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.

Il y a surement des divas mais il y a aussi des gens qui savent > mieux faire du design que les développeurs. Et vu la gueule de
quasiment la totalité des applis libres c'est assez flagrant.

Le simple fait que l'interface utilisateur soit une branche à part avec des spécialistes (voir des boites dédiés, des livres, des confs, etc) montre qu'il y a en effet sans doute des gens qui passent plus de temps sur ça que des développeurs (qu'on continue de croire comme étant l'alpha et l'omega du libre)

La question ne se pose pas pour la traduction, la documentation, l'admin système ou le marketing (entre autres). Donc je ne vois pas pourquoi ça serait différent pour le design d'interface utilisateur.

Et je pige pas non plus pourquoi on accepte parfaitement de recevoir des bugs reports pour dire "tel truc marche pas", pourquoi c'est parfaitement normal de dire "faut refaire tel lib en rust/go", mais quelqu'un qui tente de changer un truc dans le design, c'est la catastrophe.

Alors je sais pas comment ça marche pour Docker que tu cites
aussi, mais j'imagine bien qu'y a pas de mise-à-jour automatique
(surtout parce que c'est fait pour les serveurs et on veut pas
voir des trucs genre maj auto en prod!).

En fait, si tu regardes dans tout les systémes de CD, c'est un peu justement ce qui se passe. Tu pousses ton code, il passe les tests, et paf, il est déployé.

L'industrie va de plus en plus vers le fait de déployer juste en automatique. Certes, tu as des risques mais j'ai l'impression que le modèle inverse (ie, pas de mise à jour) cause plus de soucis mais de manière moins visible (ie, le cout des piles technologiques qui lagguent, le non déploiement de systèmes plus sur et plus efficaces, etc). Peut être que c'est juste aussi parce qu'il est plus répandu.

Oui, mais deltarpm a eu pendant longtemps un cout non négligeable coté serveur. Je suis pas sur que maintenant que les serveurs sont suffisament rapide pour les petits paquets, ça passe aussi bien pour les gros paquets, et qu'on se retrouve pas avec le même souci qu'avant.

Ni celui de la vérification des licences et autre trucs qu'on oublie un peu facilement jusqu'à ce qu'un SCO 2 sorte du bois et qu'on se dise "oups".

Il y a aussi de la valeur ajouté des distributions à faire un peu de vérification de sécurité (en général, je fait une passe rapide sur les paquets quand je fait une revue Fedora, histoire de pas trouver trop d'horreur).

Mais bon, tout ça, ça requiert de faire du travail, pas de reprendre les trucs upstream. Et c'est pas rpm qui rends ce travail plus complexe, ni docker/flatpack qui va le rendre plus rapide.

Alors, ayant fait une partie du portage:

• tout le code est compatible python3 à la compilation

• les modules les plus classiques sont fonctionnels. J'ai réussi à installer Openshift (95 roles via openshift-ansible) avec python 3 de bout en bout en octobre 2016.

• la liste des bugs sur python 3: https://github.com/ansible/ansible/issues?q=is%3Aopen+is%3Aissue+label%3Apython3

• la TODO list: https://github.com/ansible/ansible/projects/1

Dans la mesure ou tester la version git et tester python 3 sont assez simple ( git clone ; cd ansible ; source hacking/env-setup )
et -e ansible_python_interpreter=/usr/bin/python3, j'invite les gens à tester et à remplir des rapports de bugs. J'ai vraiment testé tout les modules des playbooks que j'utilise, j'ai mếme été jusqu'à installer un openbsd et un freebsd pour trouver des bugs potentielles avec python3.

Mais pour moi, ça marche sans souci dans la version git.

Ou ara: https://github.com/openstack/ara

Screenshot:

https://dmsimard.com/2016/11/09/visualizing-kolla-ansible-playbooks-with-ara/

Ou via the foreman:
https://theforeman.org/plugins/foreman_ansible/0.x/index.html

Ansible rends ce phénomène plus fréquent et visible, car le
mécanisme de notifications (via les handlers) est très
spécialisé et pas utilisable en toutes circonstances (par
opposition au notify/subscribe de puppet, qui permet de
coordonner n'importes quelles actions).

Pour compléter ça, il y a aussi le système de listener maintenant:
https://github.com/ansible/proposals/issues/11

J'ai pas encore utilisé, mais ça rajoute un peu de souplesse dans la gestion des handlers.

Ansible est leeeeeeeeent à coté de Puppet…

bah, y a pas de secret, ansible fait les opérations une par une, puppet envoie tout sur l'agent pour qu'il fasse 1) juste ce qu'il faut 2) en même temps. Puppet (et les autres) seront sans doute toujours plus rapide qu'Ansible.

Ensuite, James Shubin, estimé collègue et auteur de mgmt (https://github.com/purpleidea/mgmt) n’arrête pas de présenter l'outil (mgmt) partout en expliquant comment il arrive à faire un truc qui converge plus vite que Puppet et sans les soucis de Puppet (notament de version), et comment ça va révolutionner les choses. Y a des vidéos de lui sur youtube, et il va être présent au FOSDEM à Bruxelles, au config mgmt camp à Gent, et à Devconf à Brno. Son design a l'air en effet correct, et je sais qu'il a passé beaucoup de temps dessus pour avoir un bon truc.

Un "--check" sous Ansible (qui est l'équivalent) va quand même
faire certains trucs pour de vrai (notamment les installs de
packages - hé oui ! surprise ! )

Si c'est le cas, c'est un bug. Le code du module yum n'est pas censé le faire, par exemple, pkgin non plus, apt, etc, etc.

Si tu as un cas précis, je peux essayer de regarder.

Alors, c'est pas parce que par défaut, c'est agentless que tu dois t'y tenir.

Par exemple, tu peux mettre func ou salt qui ont des plugins de connexion ansible ( https://github.com/OSAS/ansible-role-salt_transport ), ( https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/connection/funcd.py ) à la place de ssh.

Tu peux aussi utiliser le mode pull, ou tu as un cron qui va faire un git pull et execution local via ansible -c local.

Tu peux vérifier que la config de ssh est bonne avant de relancer, par exemple.

Et bon, si tu vautres le réseau ou le firewall (genre paf, tu mets OUTPUT en DROP au lieu d'ACCEPT), en fonction de comment tu te vautres, Puppet ne va pas te sauver même si il a un agent, le risque n'est pas non plus nul.

Sauf erreur de ma part, certains serveurs ntp (chrony par exemple) sont capable de stocker la date/heure sur le disque pour la reprendre quand ça redémarre. Ce qui fait que sauf si tu éteint la raspberry pi pendant longtemps (ie plus que quelques minutes), ça contourne le fait de ne pas avoir de RTC.

Une autre solution, c'est de mettre un GPS dessus:
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html

Ou d'acheter une add on pour la raspberry pi. J'ai une cryptocape pour beaglebone (plus pour le TPM que pour le RTC), et y a la puce dont tu parles plus loin dessus: https://cryptotronix.com/products/cryptocape/

(mais intégré pour les boulets qui savent pas faire d’électronique comme moi)

Une liste (AMHA) plus complète se trouve aussi ici: https://diyisp.org/dokuwiki/doku.php?id=technical:dnsresolver

Tor permet de faire passer le DNS à travers le réseau.

Il suffit d'ajouter par exemple dans le fichier torrc:

DNSPort 127.0.0.125:53

Et de mettre 127.0.0.125 dans la config. J'ai rajouté par dessus ça systemd-resolvd pour faire de la verif dnssec, mais je suis pas sur que ça soit déployer en pratique à beaucoup d'endroit.

AppArmor marche sur xen, mais il est possible que ça ne marche pas sur xen de la façon dont c'est mis en place chez OVH. AppArmor a besoin d'un support kernel, donc prendre un VPS me parait prendre des risques par rapport à une machine physique à ce niveau la (vu qu'on sans doute pas trop toucher au kernel).

Et J'avais souvenir que les VPS d'OVH était des chroots openvz, mais ça a du changer visiblement.

Mais sinon, oui, l'histoire ne fait que rappeler la base des hébergeurs à bas prix, à savoir les humains du support coute de l'argent. Si le tarif est de 3€ par mois, ça fait 36€ par an, ou 360€ sur 10 ans. Une panne qui requiert d'appeler le support tout les 10 ans va bouffer la majorité du bénéfice fait sur les 360€ (car tu dois retirer de tout ça le prix du serveur à amortir, le réseau, l’électricité, la place dans le DC).

J'ai pas trop d'idée des prix de 2017, mais si je regarde les tarifs 2015 que j'ai dans ma boite mail:
un dell Poweredge R630, avec 128G de ram, 3.2T en SSD, 2 xeon E5-2690 à 2.6Ghz, ça a couté (aprés remise) ~14 000$.

On va doubler la ram pour aujourd'hui, et supposer que le cpu et le disque sont suffisant. Si tu files 2G à tout les clients dessus, tu peux en mettre 128 par serveur. Comme tu sais que tout le monde utilise pas tout, on va monter à 200 utilisateurs par machine. Chaque utilisateur doit te rapporter 70$ pour que ça soit rentable. Si on fait une grosse conversion à la louche 1$ = 1€ (parce que c'est mes calculs, les gens sont libres de faire du plus précis en réponse), ton serveur sera payé au bout de 2 ans… si l’électricité est gratuite (ce qui est pas le cas), si la place dans le DC est gratuit (ce qui est pas le cas), si l'accès internet est gratuit (ce qui est pas le cas), et que personne n'appelle le support (ce qui est pas le cas).

Si chacun a une panne en 2 ans, et que le support passe 30 minutes dessus, ça nous fait 100h de travail. Soit 3 semaines, on va rajouter par dessus la formation, les congés, les meetings etc, et on arrive à une personne à temps plein du support par serveur si il y a une panne tout les 2 ans. Donc tu va payer quelqu'un pendant 1 mois. Je laisse les gens pinaillé sur le tarif du support sur 1 mois, je vais dire 3000€ en cout pour la boite au pif (cotisations sociales comprise), ça fait une surcharge de 15€ par client.

IE, à peu prés 5 mois d'utilisation sont la juste pour traiter un incident d'une demi heure.

Donc ouais, le moyen d'être aussi bas, c'est
1) réduire le nombre d'incident via l'automatisation
2) réduire le temps passé sur chaque ticket
3) payer moins le support

si le support est pourri, c'est sans doute les conséquences de 2 et 3.

Ce qui permettrais aussi de les faire tourner avec un user différent et des privilèges non partagés. Et ce qui est le fonctionnement de tout faut mod_php, sauf erreur de ma part.

Ce qui permet aussi d'isoler les crashs à une application, etc, etc.

Et de séparer l'espace mémoire du truc avec la clé ssl de l'espace mémoire du truc avec du code complexe qui tourne.

Ça a le même intérêt que pour toute application : installation
facile et standardisée, mises à jour de sécurité gérées par la
distribution. L'intérêt est même supérieur à la moyenne vu que
les applications web sont particulièrement affectées par les
problèmes de sécurité.

Tu peux préciser "gestion des dépendances" (car mine de rien, ça commence à tirer des paquets de partout), et "installation saine". Par installation saine, je veux dire "sans que le serveur web puisse modifier son propre code car il a le droit d'écrire sur son dossier", par exemple.

Le fait aussi de placer ça au bonne endroit permet de s'assurer que selinux donne les bons labels (même si je reconnait qu'on est loin de ce qu'on pourrait faire à ce niveau la).

Et tu as aussi le fait de pouvoir vérifier ce qui est installé (rpm -Va, debsums).

Et la vérification que la licence est correct aussi.

Oui, il y a eu un système de vote, mais les systèmes de votes
sur ce genre de décisions restent problématique, et, ça met de
côté beaucoup d'utilisateurs finaux.

Ok, je vais mordre (j'ai largement répondu sur systemd depuis 4 ans, donc on va changer ).

1) en quoi c'est problématique ?

2 a) en quoi les utilisateurs finaux sont mis de coté

2 b) en quoi c'est un souci de manière pratique ?

D'après https://devuan.org/os/team/, il y a Roger Leigh, le mainteneur de sysvinit.

Je pense qu'à un moment, j'ai vu passer aussi Thorsten Glaser (qui était contre systemd, cf https://www.mirbsd.org/permalinks/wlog-10-tg_e20141119-tg.htm#e20141119-tg_wlog-10-tg )

Sinon, les autres noms ne me disent rien.

Ceci dit, au risque d'alimenter les complotistes, l’état de l'art, c'est des choses comme ça:

http://sharps.org/wp-content/uploads/BECKER-CHES.pdf

"Stealthy dopant-level hardware trojans"

Avec la réponse 2 ans plus tard:

http://eprint.iacr.org/2014/508.pdf

"Reversing Stealthy Dopant-Level Circuits"

Autre papier intéressant dans la même veine:

"Threshold-Dependent Camouflaged Cells to Secure
Circuits Against Reverse Engineering Attacks"

http://arxiv.org/pdf/1605.00684

Je propose d'adopter le même système que l’élection du doge de Venise.

Pour info: https://fr.wikipedia.org/wiki/Doge_de_Venise#.C3.89lection