wilk a écrit 1202 commentaires

  • # gpascum

    Posté par  . En réponse au journal Et vous, vous voulez qu'elle fasse quoi votre voiture autonome ?. Évalué à 7.

    Qu'elle ne se gare pas comme une m….. autrement dit qu'elle laisse de la place aux piétons et cyclistes !

  • [^] # Re: Et les autres

    Posté par  . En réponse au journal Programmer ça craint. Évalué à 8.

    Oui et non. Disons que mettre à jour un bout de code d'une appli même en prod se fait autrement plus facilement que remplacer la charpente en acier d'un immeuble de 30 étages occupé à tous les étages.

    Du coup dans le monde matériel, il y a plus de tests et de contrôles

    C'est aussi très souvent l'inverse ! Regarde l'état de nos centrales nucléaires pour citer l'exemple le plus flagrant. Je dis pas ça pour rentrer dans un débat sur le nucléaire, on le constate dans tous les domaines tous les jours. Les normes existent mais sont rarement respectées. A tel point que nos chers élus baissent les bras et rétro-pédalent régulièrement sur ces sujets (normes diesel en dernière date).

    L'informatique n'y échappe pas. Par contre contrairement au domaine matériel, on constate aussi l'inverse, où on n'hésitera pas à faire de la réplication de base de données pour la moindre petite gestion d'adhérents dans une association, du load balancing pour le moindre petit jeu amateur, des tests unitaires pour une fonction qui donne l'heure, tout ça logué scruté envoyé par sms si besoin… Ca n'est pas toujours le cas mais quand on regarde de nombreux projets libres et les confs, il me semble que le suivi est de très loin supérieur à ce qu'on voit dehors.

    Mais où sont les bugs trackers des projets matériels ?

  • # Equipe par thème

    Posté par  . En réponse au sondage Comment vous inciter à contribuer plus souvent à LinuxFr.org ?. Évalué à 6.

    Dans la FAQ :

    Je souhaite commencer une dépêche dans l'espace collaboratif et pouvoir être aidé(e) par d'autres personnes.
    Et il est donc possible pour les utilisateurs authentifiés d'aller dans l'espace de rédaction pour participer à l'écriture des dépêches proposées par d'autres visiteurs.

    Quand on veut participer il faut aller de temps en temps voir l'espace de rédaction (il y a des dépêchent qui traînent, peut-être faut-il faire le ménage ?)
    Quand on veut lancer une dépêche et être aidé il faut démarrer une dépêche et attendre patiemment que quelqu'un passe par la pour donner un coup de main.

    On pourrait former des sortes d'équipes par sujet/thème où l'on s'inscrirait pour être contacté quand une dépêche sur ce thème est lancée.

    Concrètement je n'ai pas d'idée pour que ça ne soit pas une usine à gaz…

  • [^] # Re: quel salaire

    Posté par  . En réponse au journal Dans la peau d’un entrepreneur du libre – Les choix techniques. Évalué à 3.

    Un des conseils qu'on m'a rabâché depuis le début et que j'ai eu raison de ne jamais écouter c'est de ne pas mélanger le travail et les amis.

  • # Impact marketing du libre ?

    Posté par  . En réponse au journal Dans la peau d’un entrepreneur du libre – Les choix techniques. Évalué à 10.

    Quel est à ton avis l'impact marketing de la mention "libre" ? Est-ce compris ? N'y a-t'il pas un côté péjoratif ?
    Personnellement, je fais du dev depuis le siècle dernier, j'en parle de plus en plus rarement à mes clients, ça les embrouille plus qu'autre chose, voir ça les dissuade (genre si c'est libre mon concurrent pourra l'avoir aussi ? ou bien c'est gratuit ?).
    Là où je parle du libre c'est pour les rassurer en leur disant que j'utilise les mêmes langages et que j'échange avec les ingénieurs de Google par exemple. Mais c'est rare que ça les intéresse.
    Du reste, ils s'habituent de plus en plus aux services en ligne, donc la notion de libre s'éloigne encore plus.
    Paradoxalement il n'a jamais été aussi facile de vivre grâce au libre.

  • [^] # Re: migre

    Posté par  . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 3.

    Dropbox utilise maintenant Rust et Go pour scaler.
    Ca ne veut pas dire que Python soit un truc de gamin ni que Java soit la seule alternative, mais je crois qu'on constate tous que les problèmes d'échelles sont de plus souvent résolus en utilisant la techno qui va bien pour chaque problème donné.

  • [^] # Re: Arguments ?

    Posté par  . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 8.

    En Java on code vite mais y a beaucoup à coder ;-)

  • [^] # Re: Go ?

    Posté par  . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 8.

    Bon je pense qu'il faut essayer pour être convaincu de l'intérêt du typage statique.

    Je pense que le problème vient du fait qu'on résume le problème aux "erreurs de type". Hors j'ai toujours remarqué qu'en Python j'avais vraiment très peu d'erreur de type à l'exécution, du coup je ne comprenais pas trop d'où venait cette phobie.

    Le typage statique ça n'est pas qu'une vérification de sécurité avant exécution, c'est surtout une aide à la saisie, à la refactorisation, à la documentation etc.

    Je me suis amusé à compter en Python le nombre d'erreurs que je faisais qui auraient été détectées à la saisie en Go (j'utilise vim + vim-go), c'est impressionnant ! Mais je ne m'en rendait pas compte car ce sont des erreurs qui sont très vite détectées (F5 ou test unitaire) et faciles à corriger. De même pour le temps passé à jongler avec la documentation, rien d'impossible ni bloquant, mais juste plus long.

    Donc je confirme, il faut essayer !

    ps: je sais qu'il existe des éditeurs Python qui aident plus ou moins, mais c'est beaucoup plus lourd, moins sûr et très limité.

  • [^] # Re: Fausse alerte

    Posté par  . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 3.

    Du coup plus d'interopérabilité avec d'autres technos ?

  • [^] # Re: Go ?

    Posté par  . En réponse au journal Java (EE) Sapu cépalibre.. Évalué à 9.

    Le monsieur te dit qu'il veut quelque chose de sérieux. Sérieux ça veut dire un minimum compliqué et pénible sinon c'est pas du jeu. Donc Go est hors jeu. Où plutôt Go est un jeu.

  • [^] # Re: _o/

    Posté par  . En réponse au journal C14 l'archivage chez Claude. Évalué à 2.

    Le bug a été corrigé avec un appel téléphonique pour me prévenir. Un bon point Claude.

  • [^] # Re: _o/

    Posté par  . En réponse au journal C14 l'archivage chez Claude. Évalué à 8.

    Niveau confidentialité des données y a pas mieux \o/

  • [^] # Re: Backup Incrémental ?

    Posté par  . En réponse au journal C14 l'archivage chez Claude. Évalué à 2.

    Tu as bien compris, ça n'est pas adapté à de l'incrémental.

    Ou bien avec http://mattmahoney.net/dc/zpaq.html qui permet de créer un nouveau fichier à chaque incrément et donc d'archiver ce nouveau fichier, mais ça ne serait pas très pratique pour désarchiver.

    Je n'ai pas précisé mais la suppression est également payante, c'est une opération (donc coût en fonction du volume), du coup un jonglage avec les archives aurait un coût.

  • [^] # Re: Bottle vs Flask

    Posté par  . En réponse à la dépêche Sortie de Flask 0.11. Évalué à 2.

    Ce n'est pas parce qu'il n'y a rien par défaut qu'on n'utilise rien ou qu'il faut tout refaire par soit même… Au contraire même, on choisi ce qu'on utilise donc potentiellement plus de choses si besoin.
    Inversement, dans un framework ou tout est inclus, si on doit utiliser quelque chose qui n'est pas inclus, là on va devoir "tout refaire".

  • # Pyramid

    Posté par  . En réponse à la dépêche Sortie de Flask 0.11. Évalué à 8.

    Puisqu'on est dans les comparaisons, j'aime bien Pyramid pour sa flexibilité impressionnante. Je dirai même que c'est plus un toolkit de fabrication de framework qu'un framework. Donc si on a envie de se faire son framework aux petits oignons c'est l'idéal.

    https://trypyramid.com/

  • [^] # Re: blockchain

    Posté par  . En réponse à la dépêche Point d'étape sur loi française de finances 2016 (article 88) et les logiciels libres de caisse. Évalué à 1.

    https://blogs.oracle.com/Oracle-France/entry/la_cnaf_d%C3%A9mat%C3%A9rialise_la_prime

    Et encore, c'est en Java, tu réécris tout ça en Go pour diviser par 10 ;-)
    Ce qui va poser un problème c'est le budget, il faudra le justifier sous peine de ne plus avoir autant la prochaine fois.

  • [^] # Re: Dédié

    Posté par  . En réponse au journal Du stockage en ligne (encore). Évalué à 2.

    Je disais un seul s3 dans le sens seulement sur un s3…

    J'ai rarement eu de problème à cause d'un matériel défaillant, la plupart du temps les problèmes de sauvegardes viennent d'une mauvaise configuration, le mauvais répertoire indiqué, un exclude trop vaste, un lien non suivi etc. Pour ça je préfère multiplier les méthodes plus que les supports. Par exemple j'ai une sauvegarde intégrale mais avec peu d'historique, une autre avec de l'historique sur les parties plus critiques etc.

    Tu utilises zpaq régulièrement, depuis longtemps ? La seule chose qui m'inquiète un peu c'est le dev qui a l'air un peu de considérer que c'est son jouet pour faire des expériences (d'après ce que je vois sur le forum).

  • [^] # Re: Dédié

    Posté par  . En réponse au journal Du stockage en ligne (encore). Évalué à 2.

    Évidement oui, je ne me contente pas d'un seul dédié, c'est juste pour le côté "cloud". Mais je n'aurai pas non plus confiance en un seul S3. Pas tant que le support ne soit pas fiable, mais du fait que ma propre config d'upload puisse avoir des failles, humaines (par exemple sauvegarder un mauvais dossier).

    Du coup je préfère multiplier les méthodes de sauvegardes plutôt que les sauvegardes elles mêmes. D'où mon journal sur zpaq qui complète un rsync + cp -al etc.

  • [^] # Re: Je suis entièrement pour !

    Posté par  . En réponse au journal Un hackathon linuxfr ?. Évalué à 4.

    Quelque part ça m'arrange que ce soit en RoR, ça me fait une excuse pour ne pas participer ;-p

    Mais je remercie Bruno de l'avoir fait car c'était un challenge (à l'époque RoR n'était pas si connu non ?) qu'il a réussi à mener haut la main et sorti linuxfr du bourbier php. On en bénéficie tous et surtout du fait qu'il nous fasse régulièrement bénéficier de cette expérience. C'était également le cas de templeet. Je trouve que c'est une bonne chose que linuxfr soit le fruit d'une passion, ne serait-ce que celle d'un moment (pas sûr qu'il utilise toujours Ruby non ?), plutôt que d'un consensus mou pour bénéficier de contributions. Je n'utilise pas Ruby non plus, mais je suis sur que si on voulait vraiment on pourrait contribuer quand même sans trop de difficulté (un autre dinosaure et collectionneur de langages qui parle) et que Bruno donnera volontiers le coup de main pour ne pas rester bloqué dans les méandres de Ror.

    Et sinon tout reste à faire alors. Qu'est-ce qu'on essaye d'autre comme réécriture ? Des micro-services en Go ? Je suis persuadé que Bruno ne manque pas d'idée de ce genre (mais plus de framework hein) ! Bha, finalement le dinosaure va plutôt retourner s'occuper de sa marmaille… (nouvelle excuse : si je ne contribue pas c'est à cause de mes gosses)

    C'est l'heure du goutter.

  • # Dédié

    Posté par  . En réponse au journal Du stockage en ligne (encore). Évalué à 4.

    Je préfère encore utiliser un nuage perso dans le coin d'un dédié (chez online pour ma part).
    C'est comme ça qu'a démarré amazon s3, ils ont utilisé leur architecture existante pour louer l'espace disponible. Et finalement je crois que c'est ce qui leur rapporte le plus maintenant.
    La seule contrainte que je vois c'est que la capacité est moins flexible. En revanche ça permet de faire tout un tas de vérifications et stats des données sur le serveur lui-même.

    On peut même se monter son propre s3, c'est ce que je suis entrain de m'amuser à faire avec https://minio.io + https://restic.github.io/
    Mis à part qu'il est clairement indiqué en rouge "Minio server is under active development. Do not deploy in production." ça marche et c'est vraiment très simple à déployer. Presque trop simple, on n'a pas du tout envie de tenir compte de cette note !

  • # rdedup

    Posté par  . En réponse au journal zpaq : backup incrémental avec déduplication . Évalué à 2.

    Un nouveau venu en Rust : https://github.com/dpc/rdedup

  • [^] # Re: Alternatives

    Posté par  . En réponse au journal zpaq : backup incrémental avec déduplication . Évalué à 3.

    J'ai essayé restic qui a l'air plutôt bien parti et dont le développement semble un peu plus "moderne" que zpaq (ce qui n'est pas péjoratif, loin de là). Avec une création d'exécutable multiplateforme grâce au langage Go qui est bien pratique.
    Il a l'air bien au fait de ce qui se fait avec un dépôt recensant les alternatives :
    https://github.com/restic/others
    En fait il y en a une tripotée, je ne me rendais pas compte.

    https://camlistore.org/ est prometteur mais en fait peut-être un peu trop ? Je préfère un outil de sauvegarde minimaliste quitte à lui associer d'autres outils.

    https://github.com/tsileo/blobsnap est intéressant aussi, il s'appuie sur https://github.com/tsileo/blobstash (du même auteur, Français, cocorico) un stockage clé/valeur avec déduplication

  • [^] # Re: Performances ?

    Posté par  . En réponse au journal zpaq : backup incrémental avec déduplication . Évalué à 3.

    Vu le gain que je j'ai en terme de volume, jusqu'à diviser par 10 ! Le temps de compression devient insignifiant par rapport au temps de transfert gagné.

  • [^] # Re: pas faux

    Posté par  . En réponse au journal Comment être un développeur désirable. Évalué à 3.

    arrêter de jouer à l'homme orchestre

    C'est relatif, de mon côté (indep qui ne travaille que très rarement en équipe) j'observe plutôt l'inverse. Ma tâche c'est le développement, mais du fait de gérer aussi le système ça me permet de bosser dans un environnement aux petits oignons et donc de ne pas perdre de temps à m'adapter à un système moins adapté ou que je ne maîtrise pas. Et quitte à être coupable, autant prendre les devants !

  • # VimFX

    Posté par  . En réponse au journal Quelles extensions pour votre Firefox?. Évalué à 5.

    Je ne me souviens plus pourquoi j'ai changé par rapport à vimperator… Peut-être plus rapide ?
    Pour le dev firebug, mais je me demande si ça reste indispensable vu les progrès des outils intégrés.
    Pour les pubs, rien de mieux que ce qui a été mis en commentaires.