Misc a écrit 6254 commentaires

  • [^] # Re: Et les « gestures » ?

    Posté par  (site web personnel) . En réponse au journal Microsoft voudrait de la biométrie. Évalué à 4.

    Je me demande aussi si il n'y a pas des problématiques d’accessibilité. L'informatique soit fait par et pour les gens en bonne santé en général, mais je me demande à quel point le fait de faire certains gestes peut être chiant pour certains.

  • [^] # Re: Disons que ça se développe mais ce n’est pas nouveau…

    Posté par  (site web personnel) . En réponse au journal Minage en douce. Évalué à 4.

    Le souci, c'est aussi d'avoir une monnaie connecté au reste du monde.

    Sinon, bitcoin en tant que monnaie qui s'echange que avec elle même, ça me parait globalement stable. C'est quand tu mets une valeur en monnaie traditionnelle que ça part en vrille, surtout parce que c'est non centralisé (et non régulé):

    https://davidgerard.co.uk/blockchain/2017/12/17/why-you-cant-cash-out-pt-1-why-bitcoins-price-is-largely-fictional/

  • [^] # Re: Pourquoi pas? (mais pas en douce!)

    Posté par  (site web personnel) . En réponse au journal Minage en douce. Évalué à 3.

    Ce qui est fait sur https://0x00sec.org/

    Ensuite, je sais que l'IDS du taf bloque un protocole lié à Bitcoin, pour éviter que quelqu'un installe une ferme de minage en douce dans les bureaux (et sans doute aussi pour voir les bécanes infectés), donc ce genre de méthode va sans doute à un moment poser souci.

  • [^] # Re: Disons que ça se développe mais ce n’est pas nouveau…

    Posté par  (site web personnel) . En réponse au journal Minage en douce. Évalué à 10.

    Pourtant, il y a un paquet de souci avec le concept de blockchain publique, ce qui grosso modo est un prérequis à l'idée de monnaie distribué:

    https://medium.com/@preethikasireddy/fundamental-challenges-with-public-blockchains-253c800e9428

    Je suis d'accord que le concept de blockchain est utile pour plein de choses, mais le lien liste quand même un paquet de souci à régler avant que ça soit utile à grand échelle. Et ça, c'est sans même attaquer les problèmes classiques d'un logiciel, comme l'UX, les mises à jour, etc, qui sont autant de choses à régler pour une monnai basé sur un livre de compte distribué.

    Pour preuve, des liens que j'ai vu passer y a moins de 2 semaines:
    https://codesuppository.blogspot.fr/2017/12/iota-tangled-mess.html?m=1

    https://twitter.com/TedOnPrivacy/status/940588631709896704

    Et c'est des expériences corroboré par les histoires d'un collègue qui a tenté d'acheter et de vendre du bitcoin.

    Un autre lien aussi assez révélateur sur l'état de l'ecosystème:

    https://magoo.github.io/Blockchain-Graveyard/ 47 incidents

    Tu peux rajouter une autre liste (qui fait doublon, mais avec 3 autres soucis pas dans la première):

    https://storeofvalue.github.io/posts/cryptocurrency-hacks-so-far-august-24th/

    On arrive quand même à ~ 50 hacks principalement sur les 3/4 dernières années. Ça fait plus que 1 par mois.

    Donc l'idée est sans doute séduisante, mais ça scale pas, c'est rempli d'escrocs et c'est mal foutu.

    Et faut pas oublier que Bitcoin a 8 ans. C'est aussi vieux que golang, ou à peine plus jeune qu'Android sorti 1 an avant. Je veux bien que ça mette du temps à avancer, mais j'aurais tendance à croire qu'en 8 ans, on aurait pu prévoir ou voir les soucis existants quand même.

  • [^] # Re: C'est pas vendredi

    Posté par  (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 4.

    En effet, si c'est le cas, ma réponse serait différente.

    A savoir qu'il y a toujours pas de changement de casse dans les commandes. La commande systemctl est en minuscule. Si je m'en tiens à l'exemple, le reproche est sur l'argument, mais dans ce cas, c'est cohérent parce que l'argument est un bout de configuration, une option dans les fichiers .services et autres.

    C'est la propriété "CPUQuota" qui est changé. Et la, je pense que personne ne va dire "on a jamais eu de CamelCase dans la configuration d'un soft", parce que c'est faux. L'exemple le plus parlant serait Apache, mais je peux citer aussi OpenSSH comme logiciel présent dans le systéme de base de tout les BSD.

    Les commandes utilisent aussi la casse pour avoir plus d'options (entre -C et -c pour tar), c'est donc pas non plus rare.

    Alors oui, du coup, l'usage du CamelCAse déborde vers la CLI, et je comprends que ça puisse déranger les gens, sans doute parce que comme tout compromis fait, quelqu'un ne va pas être 100% satisfait.

    Il y a sans doute des gens qui préfèrent tout en minuscule parce que c'est plus facile à retenir, et d'autres qui préfèrent en CamelCase parce que c'est plus facile à lire. Mais tu peux difficilement satisfaire tout le monde (sauf à supporter tout, mais d'un coup, tu va avoir de l'inconsistence dans la doc ).

    De la même façon que tu ne peux pas avoir un truc rapide à taper comme "cp" et en même temps avoir un truc clire comme "copy".

  • [^] # Re: C'est pas vendredi

    Posté par  (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 4.

    Tu gères comment la dépendances entre les services au démarrage ?

    Sur NetBSD et FreeBSD, c'est via des headers proches de la LSB (donc provides, requires) dans les scripts d'init.

    Sur OpenBSD, ça n'a pas l'air de le faire, mais j'ai regardé en détail (j'ai juste fait du ssh et des rapides coups d'oeils à des scripts au pif).

    Le démarrage conditionnel ?

    Sur OpenBSD, via une fonction dans le script d'init (exemple, le script de démarrage de nfsd avec la fonction rc_pre() ).

    Sur FreeBSD et NetBSD, tu déclares une variable start_precmd qui pointe vers une fonction , comme pour OpenBSD.

    Au final, la différences est de savoir si tu exposes un langage de programmation complet, avec tout ce que ça entraine comme bons et mauvais cotés, ou pas. J'ai tendance à favoriser 'approche configuration plutôt que l'approche programmation, vu que tu arrives assez vite à rajouter de la complexité, et à avoir du code dupliqué partout. Mais je comprends aussi que des gens préfèrent l'autre approche.

  • [^] # Re: C'est pas vendredi

    Posté par  (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 4.

    Te rends-tu compte que ni la complétion ni le man ne m'ont
    aidé???

    On a pas du lire la même page de man.

    set-property NAME ASSIGNMENT...
    Set the specified unit properties at runtime where this is
    supported. This allows changing configuration parameter properties
    such as resource control settings at runtime. Not all properties
    may be changed at runtime, but many resource control settings
    (primarily those in systemd.resource-control(5)) may. The changes
    are applied instantly, and stored on disk for future boots, unless
    --runtime is passed, in which case the settings only apply until
    the next reboot. The syntax of the property assignment follows
    closely the syntax of assignments in unit files.

    C'est la page de man de systemctl sur une RHEL 7. On peut pas dire que ça soit la dernière version ou quelqu'un aurait vite fait corriger la doc pour te contredire, c'est une version 219, qui date quand même d'il y a un ou deux ans. Et parce que je part pas du principe que tu mens, j'ai aussi vérifié sur une Fedora, et la page de man dit grosso modo la même chose.

    Encore une fois, je veux bien reconnaitre qu'il y a beaucoup à lire, parce que il y a beaucoup de features, mais dire "la page de man ne m'a pas aidé" me semble être un raccourci qui n'a pas l'air de resister à un examen rapide de la dite page de man, sauf si tu as eu une page de man différente.

    Il n'y a jamais eu de "casse" dans les commandes systèmes sous
    Unix/Linux*.

    Foutaises.

    La migration de ifconfig vers ip a commencé y a plus de 10 ans.

    L'interface de firewall sous Linux a changé 3 fois avant d'arriver à iptables/netfilter et va encore changer avec nftables.

    Solaris a eu des changements de systémes d'init et des tas de commandes nouvelles avec Solaris 10 (sauf erreur de ma part).

    Apt-get est devenu Apt sur debian (ou Aptitude pendant un temps, bien que les 2 vont sans doute cohabiter pendant longtemps). Yum est devenu DNF.

    Et même au niveau du noyau, quand j'ai commencé, c'est sur /dev/hda1 que j'avais mon bootloader lilo, avec un /dev statique remplacé par devfs assez rapidement.

    Ou sur FreeBSD, le fait d'avoir intégré zfs a forcément entrainé des changements de commandes pour gérer les partitions.

    C'est dingue, on en est à ne me plus tolèrer la critique sur
    systemd alors qu'on ne rejete aucunement toute le framework.

    C'est bien la preuve que c'est rien de personnel que de répondre sur le point précis sans se préoccuper du reste.

  • [^] # Re: Monopole ?

    Posté par  (site web personnel) . En réponse au journal la neutralité du net bronsonisée. Évalué à 3.

    Ce qui est surtout amusant, c'est qu'au final, il n'y avait pas eu de régulation pendant trés longtemps, sauf depuis décembre 2015. Autant dire que 2 ans, ça a pas du changer des masses.

    Bien que la façon dont ça a été fait est scandaleuse, et tout un tas de choses autour, les discussions autour des conséquences ont quand même jamais trop pointés ce qui est arrivé avant, quand ça n'était pas un souci, et je trouve que ça manque.

    Non pas que je fasse confiance à Comcast et consort pour pas faire de la merde, mais j'ai quand même aussi du mal avec les hyperboles réthoriques (surtout que les gens n'ont pas de problème à tous aller chez le même fournisseur de mail, et ou on s’aperçoit que les gens sont parfaitement ok avec un monopole tant qu'il fait bien son boulot, mais vont évoqués des grands principes quand c'est plus le cas)

  • [^] # Re: C'est pas vendredi

    Posté par  (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 2.

    S'il s'agit des accès disques

    Autant pour moi, c'était pas dans la page de man de rctl sur le freebsd 10 que j'ai regardé.

    J'ai beaucoup de mal à voir la pertinence d'une limitation sur
    ces ressources, sauf peut-être dans le cas d'une jail ou
    d'un process (et encore).

    L'idée principal, c'est si tu veux pas que tes backups fassent des I/O qui pourrait ralentir ton site web, ce genre de choses. J'aurais en effet tendance à dire que si tu es à ce niveau de détails, tu as sans doute plus besoin de racheter une machine ou des disques plus rapides, mais ça ne parait pas inutile.

  • [^] # Re: C'est pas vendredi

    Posté par  (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 5.

    Rien à voir avec de la psychorigidité, tu fais comment pour
    retenir tout ça???

    Comme tout le reste, tu lit la doc, elle est la pour ça.

    Les devs passent leur temps à chercher des trucs sur Google, les sysadmins aussi. Croire que ça n'arrive pas, ou que ça n'est pas la norme, c'est malsain.

    Malsain parce que c'est faire croire que les ingés ont des capacités mémoriels au dela du raisonnable, et faire douter les gens qui ont des capacités normales en se disant "j'arrive pa sà retenir, je suis pas normal", ou pour les plus égocentriques "j'arrive pas à retenir, le soft doit être de la merde".

    Je dit pas qu'on doit pas faire un effort pour la cohérence, mais non, on peut pas tout retenir, et c'est normal, et c'est pas requis. Savoir que tu peux limiter le cpu devrait suffire.

    Quant aux "shares" cpu en %, ça ne semblent pas implémentés
    sous FreeBSD, il n'y a qu'une capacité temporelle (cputime)

    En l'occurrence, je pense que tu te trompes.La page de man parle de "pcpu":

    pcpu %CPU, in percents of a single CPU core
    Ensuite, c'est tout à la fin de la page de man, donc je comprends que ça puisse passer inaperçu.

  • [^] # Re: Oui et non

    Posté par  (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 3.

    Les ports ne sont pas testés et comment pourrait-il en être
    autrement ?

    Deja, en mettant en place un process pour ça. Je sais bien que c'est plus facile à dire qu'à faire, mais si je prends l'exemple d'une distribution comme Fedora, il y a un systéme en 2 temps. D'abord le paquet va dans updates-testing, puis dans update quand suffisament de gens ont validés le paquet. Installer un paquet depuis la version updates-testing, c'est un switch à donner. Revenir en arriére est aussi simple.

    Tu as une incitation à vérifier les paquets (bien que faible), et je pense que le processus pourrait aller plus loin, en laissant les gens s'inscrire comme testeur officiel d'un paquet, et donc en ayant des notifications pour le paquet en ayant directement les versions de tests, etc.

    Ou encore, aller vers plus d'automatisation. Avoir un truc qui automatiquement déploie le paquet (style piuparts), avoir un outil qui lance des tests basiques (exemple, un playbook ansible qui install un serveur httpd de base et qui le lance, verifie que ça écoute sur le port 80).

    FreeBSD, y a pas tout ça que je sache. Du coup, oui, structurellement, le test est difficile si on suppose que ça va tomber sur une et une seule personne, à savoir le committer.

    Et pourtant, la communauté FreeBSD est composé de gens avec des compétences, mais il n'y a pas l'air d'avoir d'efforts pour les utiliser.

    Ensuite et encore une fois, je ne dit pas que c'est facile. Les ports étant distribués via svn (sauf erreur de ma part), et avoir une branche par version de test ne me parait pas terrible. Le tooling autour bouge bien, mais l'infrastructure est pas maintenu de maniére ouverte, sans doute plus pour des raisons de ressources et d'historique que pour autre choses. Du coup, oui, faire changer les choses va prendre du temps.

    Mais c'est faisable, et dire "Debian a du monde, et pas FreeBSD", c'est à mon avis confondre cause et conséquence. Debian a des gens qui testent parce c'est faisable (faciliter de mise à jour vers testing, incitation social à le faire, etc). Fedora a du monde qui teste pour les mes raisons avec des mécanismes différents. FreeBSD n'a pas l'air d'avoir ça, donc ça n'arrive pas.

    Ensuite, je peux me tromper, peut etre que c'est autre chose.

  • [^] # Re: C'est pas vendredi

    Posté par  (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 3.

    C'est pas non plus strictement équivalent, vu que system (et Linux) est aussi capable de limiter les I/Os, ce qui ne semble pas être le cas sur FreeBSD (en tout cas, pas sur FreeBSD 10 d'après la doc).

    Je reconnait que FreeBSD a des trucs en plus, mais à choisir entre le fait de limiter le nombre de PTY et limiter le disque, j'ai quand même le sentiment que le partage du disque va plus souvent me servir.

  • [^] # Re: C'est pas vendredi

    Posté par  (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 6.

    En vrai, le problème de la version d'un OS n'en est pas un.
    Quand tout bouge tout le temps, on automatise beaucoup le
    provisionnement des serveurs/VM et l'install des softs. L'OS
    entre dans le tronc commun et n'est plus vraiment un point
    différenciant (sauf dans des cas très particuliers).

    Ceci dit, il y a suffisament de changement pour que l'automatisation puisse devenir un truc relou à maintenir. Par exemple, j'ai fait beaucoup d'automatisation via Ansible, et l'intégration avec l'OS a son importance (genre la gestion du firewall, du reaseau, etc, qui change de version majeur de RHEL en version majeur de RHEL).

    Aujourd'hui, au niveau pro, je reste sur Debian car c'est une des
    distribs les plus utilisées et possédant un des écosystèmes les
    plus gros et varié. Contrairement à FreeBSD, justement.
    Et ça, c'est une différence nette entre les 2 qui rend la 1ère
    bien plus "professionnelle" que le second…

    Oui, pour reprendre encore une fois Ansible, j'ai du rajouter une paire de trucs pour NetBSD (support de la detection de pkgin, divers facts, etc), justement parce que la communauté semble moins active. J'ai toujours pas trouvé de méthode propre pour l'installation automatique de VM FreeBSD via virt-install, et j'ai pas d'image officiel pour usage dans un cloud openstack (Rackspace dans mon cas) pour NetBSD.

    C'est ça aussi l'écosystéme et son intégration.

  • [^] # Re: C'est pas vendredi

    Posté par  (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 8.

    Pour OpenVz, je n'ai pas dit que c'était de la faute de l'un
    ou l'autre. Mais qu'est ce que vient foutre un outil de
    Virtualisation dans tout les OS si la version d'après plus rien
    n'est supporté, sérieusement c'est quoi cette organisation ?

    En l'occurrence, c'est OpenVZ qui a fait le choix d'être en dehors du kernel.

    Après des années et des années de "oui, on réécrit ça en
    upstream dans le kernel, c'est pour bientôt" je ne sais pas si
    ça a fini par évoluer." J'crois que faut utiliser "Devuan" un
    un truc comme ça enfin encore une énième bidouille. J'ai lâche
    l'affaire, bref j'ai bien perdu mon temps avec OpenVZ. Ca va
    que c'était pour un usage perso, mais j'imagine si j'avais
    monté un business articulé entièrement autour de cette solution
    bonjour le merdier …

    Alors je pense que si tu avais monter un business, soit tu l'aurais fait sur la version communautaire, et dans ce cas, tout le monde t'aurais dit "ne pas prendre des trucs non mergés upstream". Soit tu aurais payé auprés de la boite derrière openvz, et le support est la pour toi.

    Pour Iptable, clairement ça me semble à la ramasse, j'ai pas
    envie de préciser ceux qui ont touchés les deux savent de quoi
    je parle.

    Y a pas 3 firewalls sur FreeBSD ?

    Parce que bon, tu parles de coherence, mais si j'ai le choix entre pf (ou un fork différent d'openbsd), ipfw, et ipf, ça fait un peu tache dans la partie "cohérence".

    De surcroit, aucun n'est extensible comme le serait netfilter (ou du moins, pf n'avais pas l'air à l'époque ou c’était mon taf de faire du firewall, mais peut être que c'est le cas maintenant)

    Mais qui à la maison ou sur son Kimsufi ou chez soit a besoin
    d'implétementer HAST/CARP ?!

    CARP est implementé dans FreeBSD 10:
    https://www.freebsd.org/doc/handbook/carp.html

    T'as une ligne à ajouter dans un seul fichier, toujours le
    même, partout tout le temps. C'est quoi ce triturage d'esprit ?

    Je suis d'accord, c'est pour ça que j'utilise un outil de gestion de config qui fait une abstraction sur tout ça.

    Marre des bricoleurs, des bidouilleurs, 5 façons de relancer un
    service, 2 façons de faire les mises à jour, et la doc elle est
    faite quand ?

    En prenant une distribution d'entreprise, tu as la doc. Vu que tu dit que Debian et RHEL, c'est kifkif, je vais donc comparé avec RHEL et surprise, tu as une tonne de doc traduite et vérifié sur
    https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/

    J'veux dire remplacer des AIX par des RedHat pour faire tourner
    des batchs, c'est un peu de la blague quand même ?!

    Visiblement non. À un moment, faut se dire 2 choses. Soit tu as une idée de génie et le reste du monde ne sait pas ce qu'il fait. Soit tu as pas toutes les infos, et c'est pas une idée de génie.

    La, tu as pas l'air d'avoir des idées de génie.

    Si y a un truc que j'adore au taf c'est te connecter sur une
    machine tomber sur une vieille merde du genre RH 5.4, alors que
    y a 2 minutes t'étais quand même une 6.5 récente (rire), et pif
    ya plus rien qu'est pareil rien n'est ISO, un vrai merdier.
    Comment veux-tu gérer un parc ISO ? Moi j'appelle pas ça être
    carré.

    Ma foi, va demander à tes admins la raison de pas avoir fait la mise à jour. Je sais que c'est pas une question de cout, c'est le même prix dans un cas et dans l'autre. C'est peut être une question de temps, mais RHEL 7 est deja sorti y a longtemps, donc c'est pas vraiment "en regarde et on mets à jour plus tard".

    Il est fort probable que la raison soit sans doute plus complexe que tu crois, et que FreeBSD ne change rien à ça.

  • # En prévision de Vendredi

    Posté par  (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 3.

    En voyant le programme du 34C3, j'ai vu https://fahrplan.events.ccc.de/congress/2017/Fahrplan/events/8968.html

    Et je me suis dit "ça a l'air cool comme présentation, mais est ce que par hasard, je l'aurais pas déjà vu ?". Et oui, la présentation a déjà été donné à Defcon 25:

    https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Ilja-van-Sprundel-BSD-Kern-Vulns.pdf

    Du coup, je laisse les gens tirer les conclusions, c'est sur les slides (teaser: 115 bugs de sécu en 90 jours)

  • [^] # Re: Ah les BSDistes

    Posté par  (site web personnel) . En réponse au journal Debian sur mon serveur plus jamais, de chez jamais.. Évalué à 4.

    Le whitelist/blacklist oui mais le reste IPtables fait très bien…
    Et pas besoin de troller avec fail2ban qui ne répond pas du tout
    au même besoin. Si pour toi, bloquer en fonction du nombre de
    tentatives de connexion c'est une bonne idée, alors franchement,
    je sais pas où tu bosses…

    Netfilter/iptable a le support d'ipset, ce qui est grosso modo suffisant pour faire des blacklists/whitelists.

    Et iptables/netfilter fait en effet aussi le matching par paquet vu par seconde, etc.

  • [^] # Re: Jeton à l'avance

    Posté par  (site web personnel) . En réponse au journal Le LUKS, version 2. Évalué à 6.

    Oui, genre tang/clevis, comme expliqué sur https://blog.delouw.ch/2017/10/01/leveraging-network-bound-disk-encryption-at-enterprise-scale/

    Tang est dispo dans Centos 7.4 et Fedora, mais j’espère que ça va vite être adopté par les autres distributions Linux.

  • [^] # Re: Et les poles open-source de ces entreprises ?

    Posté par  (site web personnel) . En réponse au sondage Travailler pour les GAFAM. Évalué à 3.

    Tu veux dire "sont leaders" quand on retire les boites qui font de l'open source depuis le début ? (Suse, Canonical, Red hat pour les distributions, mais aussi du Dalibo, Objectif libre, Logilab pour citer des français plus petits) ?

    Parce que bon, c'est bien joli de citer les 20% de Google, mais au final, la grosse partie du code produit est proprio et le resteras.

  • [^] # Re: Je pense que tu va pas aimer mes réponses

    Posté par  (site web personnel) . En réponse au journal Votre rapport à l’anglais ?. Évalué à 5.

    En effet, (pour ma defense, j'ai pas dormi de la nuit)

  • # Je pense que tu va pas aimer mes réponses

    Posté par  (site web personnel) . En réponse au journal Votre rapport à l’anglais ?. Évalué à 5.

    Quel est ton rapport à l'anglais ?

    Il est bon. J'ai déjà donné des confs en Amérique du Nord, je fait des confcalls 3 fois par semaine dans la langue, je fait des jeux de mots pourris assez régulièrement. Je suis fatigué après une journée, mais moins qu'avant.

    Comment as-tu fait pour le parler de façon acceptable ?

    En pratiquant. D'abord, la lecture, ce que tu sembles deja réussir. Ensuite à l'écrire. Puis, à force de l'écouter (par exemple, des vidéos de conférence sur youtube) et de tenter de le parler, ça s'améliore. Le truc, c'est d'avoir des gens compréhensifs face à toi, et de persévérer.

    Je sais que ç'est pas simple et c'était pas simple pour moi non plus. Je sais que les gens se sentent ridicule, qu'on se sent con à ne pas trouver ses mots, qu'on est frustré. Je parle bien anglais, mais je galère sur d'autres langues, donc je suis pas étranger à ce que tu vis.

    J'ai appris l'anglais à l'école en 3eme langue. J'ai fait 4 mois à l'étranger dans une fac anglophone. J'ai aucun souvenir d'avoir eu des soucis, mais je ne doute pas que j'en ai eu. J'ai juste oublié, et ça finit par passer.

    Comment tu fais pour ne pas être stressé avant/pendant un call
    ?

    J'ai l'habitude. Mais oui, au début, c'était pas simple. On est passé à des videos conférence, ce qui permet déjà de voir qui parle, parce qu'en vidéoconférence audio uniquement, c'était horrible.

    Est-ce que tu pourrais être dans l'entreprise où tu es
    aujourd'hui si tu ne parlais pas anglais ?

    Non. Je bosse pour une boite US, les 3 gens entre moi et le PDG ont tous l'anglais US comme langue maternelle. Le PDG aussi. Et je pense plus de 75% de mon département.

    Mon entretien d'embauche était en anglais.

    Si je parlait pas anglais, j'aurais pas pu rentrer dans la boite il y a 6 ans. J'aurais sans doute eu du mal à parler à des gens sur les projets libres à l'époque y a 10 ans.

    Est-ce que tu as dû te farcir des séries américaines en VO
    alors que tu détestes ça ?

    Non. Si tu détestes ça, tu as plusieurs autres choix. Tu peux prendre un film que tu aimes bien, que tu connais par coeur et le revoir, en anglais.

    Tu peux regarder des vidéos de conférence sur youtube sur un sujet que tu aimes, même au ralenti, tu as le droit. Si tu piges pas un mot, tu as le droit d'arrêter. Tu as le droit de revenir en arrière, de demander à quelqu'un, de mettre les sous titres. De regarder que 5 minutes à la fois parce que tu es trop fatigué.

    Mais ça, ça n'aide que pour la compréhension, ce qui est déjà bien, mais ça va pas t'aider à surmonter ta peur.

    Pour parler, bah, faut se lancer.

    Tu peux aller à des groupes de discussions (y en sur meetup.com), tu peux (sous réserve de pognon/liberté) aller t'expatrier un temps. Tu peux demander des cours dans la cadre du droit à la formation. Tu peux utiliser duolingo ou autre applications. Tu peux faire un karaoké. Tu peux parler avec quelqu'un qui parle anglais pour t'entrainer.

    Mais c'est comme tout, c'est qu'une question de pratique. Crois moi, ça s'améliore à la fin. Pas forcément au bout d'une semaine, ni même d'un mois, mais ça s'améliore.

    Et non, tu n'es pas seul. Même si c'est pas mon cas, je connais plein de gens qui ont du mal avec l'anglais.

  • [^] # Re: Le noeud du problème

    Posté par  (site web personnel) . En réponse au journal Retour d'expérience d'une petite administration sous linux depuis 8 ans qui fait marche arrière. Évalué à 4.

    Je suis d'accord qu'une cause c'est ça, mais ce qui est
    intéressant c'est que Red Hat aurait pu avoir le même problème
    sur le serveur, mais a réussit à le contourner par la
    certification fabricant. (certains n'aiment pas ça d'ailleurs,
    mais globalement on peut quand même dire que ça a fait avancer
    le libre, surtout que RedHat a eu une stratégie long terme en
    étant un gros contributeur du logiciel libre).

    C'est marrant, parce qu'il y a une demande pour avoir du matos qui marche sous Linux. Et c'est quoi du matos qui marche sous Linux si c'est pas du matos certifié ?

    Il y a une demande, mais pas suffisante pour payer ça (parce que des machines certifiés desktop, y a eu des tentatives d'aussi loin que je me souvienne, Mandrakesoft en a eu, Red hat en a eu, Suse en a eu, Canonical en a eu, et en a encore via Dell). Et pourtant, j'en croise très rarement. Encore une fois, la demande ne suit pas les moyens, parce que quand les gens disent "je veux tel truc", c'est "je veux tel truc mais sans payer trop cher" (ce que je peux comprendre, l'argent pousse pas sur les arbres).

    Dans le b2c il faut investir en amont et attendre une réponse
    du public qui sera en plus longue à venir et avec des besoins
    plus hétérogènes et donc un écosystème plus riche qu'il faut
    réussir à emporter avec soi.

    Il faut surtout avoir la logistique qui va avec. Il y a 15 ans, c'était passer par la Fnac, Surcouf, etc. Il y a 5 ans, c’était ce que Mozilla a tenté avec Firefox OS. On sait comment ça s'est fini hélas, et c'est pas faute d'avoir tenté de faire au mieux de la part des acteurs du libre.

    Aujourd'hui, les seules qui se débrouillent sur le marché, c'est des petites boites comme system76 ou purism. Et je pense principalement parce qu'elles ont du matériel reconditionné et pas besoin de magasin physique (merci le web).

    Et quand on regarde ce qui est arrivé, ceux qui ont réussi à mettre du Linux pour le grand publique, c'est Google. Et ils ont réussi en créant un écosystème de zéro, mais surtout en créant un écosystème proprio et générateur d'argent. Personnellement, j’abhorre Android et son écosystème (parce que grandement proprio, parce que grandement non maintenu, parce que rempli de mouchard, etc, etc), mais je reconnait qu'ils ont rendu ça attractif d'une façon qui n'arriverais sans doute pas sur le bureau pour nos distributions classiques.

  • [^] # Re: Le noeud du problème

    Posté par  (site web personnel) . En réponse au journal Retour d'expérience d'une petite administration sous linux depuis 8 ans qui fait marche arrière. Évalué à 7.

    Son journal semble dire que la les moyens ont été mis.

    Je ne dit pas que les moyens ne sont pas mis dans le cas présenté, et pour être franc, je ne parle même pas de ce cas en particulier. Mais mettre les moyens ne suffit pas toujours, ni même ne décrit grand chose, car mettre les moyens ne dit pas "mettre les moyens suffisant".

    Tu peux mettre les moyens pour faire marcher quelque chose, ça veut pas dire que ça va améliorer les choses pour tout le monde. C'est typiquement tout le souci d'avoir une version custom d'une distribution Linux. Les moyens sont mis pour que ça marche chez l'utilisateur final, en ayant des admins pour que la plateforme marche, en faisant des backports et des modifs. Mais ça rends rarement la migration et/ou le support des autres plus simples et moins couteux. Donc ça fait pas avancer le schmilblick.

    Les fabricants ne s'intéressent que peu a la plateforme. D'une
    part parce qu'elle est minoritaire et, dans une moindre mesure,
    car aucun commercial / programme de certification ne leur donne
    un joli logo ou autre. Bref il y a peu d'incentive (motivation
    par la récompense)

    Pas vraiment, y a des programmes de certifs pour un certains nombres de distributions avec un acteur commercial (exemple, RHEL, SLES, et Ubuntu ). Ça reste minoritaire, mais pas parce que personne ne donne de logo.

    pour pas mal de logiciels, il y a une difficulté de financement /
    modèle économique,

    ce qui est mon point. On vends le truc comme étant pas cher, ben y a pas d'argent qui rentre.

    la pluralité des solutions et de leur composition multiplient
    les chances d'anomalies

    Encore une fois, il y a des distributions qui vont faire des choix. Mais curieusement, les gens convaincu du libre ne veulent pas de ça, voir boude l'idée. Juste sur les environnement de bureau, tout le monde veut avoir son favori dans chaque distribution. Et tout le monde veut tout avoir à jour, mais stable. Et gratos. Avec des changements, mais sans avoir à changer la doc et/ou changer l'UX. Et j'ai dit sans bugs ?

    Redhat a réussi ça sur le serveur, mais pour le bureau, le
    marché semble plus difficile à attaquer et satisfaire…

    Parce que les examples de desktop qu'on donne sont surtout des examples ou l'argent ne remonte pas vers les éditeurs.

    Prenons les divers projets phares de migration sur Linux sur le desktop.

    L'assemblée nationale en France, c'est Linagora qui a eu le marché à l'époque, la boite a mis 1 personne qui a fait un dérivé de Kubuntu, et pas un centime n'est sans rien payer à Canonical que je sache.

    La province autonome d'Estramadura, ils sont parti sur un dérivé de Debian (GNU/Linex)

    La ville de Munich, ils sont parti sur une distro custom, encore une Debian.

    3 cas, 3 fois ou l'argent n'a pas été filé à un éditeur, avec un intermédiaire qui a du se financer pas mal. Quand l'éditeur reverse son obole au libre, ça donne un secteur sain, mais en général, on te file des thunes pour un service, et ce qui pourrait aller au logiciel libre, c'est ce qui reste. Pire encore, vu qu'on parle à chaque fois d'une distro custom, il y a pas de partage des améliorations, cf ce que j'ai dit plus haut.

    Ensuite, y en a qui font les choses proprement, par exemple Google. L'entreprise a une distro custom (surprise), mais payent (ou payaient) Canonical pour le support. Et c'est plus parce que Google a du pognon à perdre et pour financer le libre de façon indirect qu'autre chose, AMHA.

    Et pourtant, des clients sur le desktop, y en a. La division Desktop de RH est auto suffisante si j'en croit les gens qui bossent la bas (e.g., ça rapporte assez pour embaucher du monde et faire des choses). Et c'est pas non plus rare d'avoir des stations de travail dans certains secteurs spécialisés (exemple, Pixar a des stations de travail sous RHEL, ma fac à Montreal en avait, l'université de Caroline du Nord aussi) si j'en croit une rapide recherche sur le web (exemple: https://www.reddit.com/r/linux/comments/71mx9s/how_many_of_you_actually_use_red_hat_enterprise/ ). Et pas que RH, je sais que Qualcomm avait des postes sous Ubuntu, et je suis sur que quelqu'un peut me donner des examples de client sous SLES pour le desktop.

    Mais la différence entre les examples que j'ai donné au début et ceux la, c'est qu'il s'agit de postes bureautiques vs des stations de travail. Et quand je dit "station de travail", je parle de trucs qui étaient sous Unix il y a 20 ou 30 ans (Irix, Solaris), dans des secteurs ou on s'attend à dépenser de l'argent pour ça.

    Pas sur le poste bureautique moyen.

  • # Le noeud du problème

    Posté par  (site web personnel) . En réponse au journal Retour d'expérience d'une petite administration sous linux depuis 8 ans qui fait marche arrière. Évalué à 9.

    On voit directement les secteurs qui sont soutenus par les
    entreprises.

    Je pense que c'est le noeud du problème. On vends l'idée d'utiliser Linux pour économiser de l'argent, ce qui aboutit juste à un secteur économique anémique, vu que les gens dépensent moins pour ça la ou je pense qu'il faut dépenser plus.

    Je comprends bien que le prix soit un levier puissant, mais sur le long terme, ça n'aide pas à atteindre un équilibre.

  • [^] # Re: Abandon de GlusterFS ?

    Posté par  (site web personnel) . En réponse au journal Retour d'expérience d'une petite administration sous linux depuis 8 ans qui fait marche arrière. Évalué à 2.

    C'est pas juste Glusterfs, c'est les systèmes de fichiers distribués et réseaux. Lire 100G par fichier de 1k, ça implique d elire une tonne de meta données et de faire une tone d'aller retour. Lire 100G d'un coup, c'est juste ça, 100G de transfert.

    Ensuite, il y a du tuning à faire sans doute pour améliorer les choses, mais il y a des moments ou la latence réseau est visible, et le cas des petits fichiers en fait parti.

  • [^] # Re: on vit une époque formidable

    Posté par  (site web personnel) . En réponse au journal Comment bloquer 280M de dollars en éther . Évalué à 3.

    Oui, ça viendrait à personne d'utiliser des arbres de Merkel pour des choses comme la gestion du code source ou ce genre de trucs au lieu d'une base de données.