woffer a écrit 69 commentaires

  • [^] # Re: RMS

    Posté par  . En réponse au journal Kernel-5.1-gnu. Évalué à 5.

    Il me semble peut-être à tort que Google utilise le concept des micro kernel pour son Fuchsia OS.

  • [^] # Re: Vallée de l'étrange

    Posté par  . En réponse au journal Cette personne n'existe pas. Évalué à 3.

    Moi, j'en ai eu au moins 1 sur une trentaine de visages demandés.

  • [^] # Re: drone.io

    Posté par  . En réponse au journal Mettre en place des build automatiques avec jenkins et docker. Évalué à 1.

    Les runners de gitlab ci sont écrits en Go. Donc, j'imagine que ça ne doit pas prendre beaucoup de RAM.

  • # drone.io

    Posté par  . En réponse au journal Mettre en place des build automatiques avec jenkins et docker. Évalué à 4.

    Hello,
    Quelqu'un a-t-il déjà essayé drone?

  • # Sortir du lot

    Posté par  . En réponse au journal Huit ans et plus toutes ses dents. Évalué à 3. Dernière modification le 28/12/18 à 16:47.

    Pourquoi ne pas sortir du lot en proposant des compétences plus rares mais utiles ? Je pense notamment au Go qui peut être utilisé dans pour le développement dans différents domaines comme le devops ou le backend.

  • [^] # Re: Go Go Go :)

    Posté par  . En réponse au journal recherche-totoz en JavaScript. Évalué à 1.

    Bonne question merci.
    Il faut utiliser le principe du fan-in fan-out qui permet de paralléliser N requêtes et les merger voir annuler celles qui restent si une échoue. Go montre toute sa puissance ici.

  • [^] # Re: Go Go Go :)

    Posté par  . En réponse au journal recherche-totoz en JavaScript. Évalué à 1. Dernière modification le 02/12/18 à 10:47.

    Je suis complètement en accord avec toi sauf malheureusement quand les librairies n'utilisent pas Netty ou d'autres (e.g. Apache Mina). Dans mes précédents développements (je travaille pour un grand telco français), nous devions nous interconnecter avec une plateforme d'accès gérant plusieurs millions de clients. Nous utilisions un client radius en Java qui n'utilisait pas les nio. Donc, nous étions obligés de configurer nos pools de threads pour ne pas dégrader la QoS de notre plate-forme avec des pools de threads vidés car le serveur radius était par moment un peu long à répondre…

    Alors qu'en Go, l'asynchronisme (via epoll sous linux) est obligatoire car géré par le runtime de façon transparente.

    De plus, comme je l'ai déjà dit, je préfère que le code soit écrit en synchrone qu'en asynchrone car beaucoup plus simple maintenir par la suite surtout par quelqu'un d'autre.

  • [^] # Re: Go Go Go :)

    Posté par  . En réponse au journal recherche-totoz en JavaScript. Évalué à 1. Dernière modification le 01/12/18 à 20:12.

    C'est justement l'intérêt de Go, qui contrairement à Java par exemple, ne bloque pas les threads systèmes sur les entrées/sorties réseaux. C'est pour cela que Go propose que des clients synchrones d'un point de vue des goroutines dans son SDK.

    Je peux te dire que venant du monde Java backend, cela a toujours été l'horreur de configurer la taille des pool de threads (souvent fait au doigt mouillé) d'autant plus quand tu accèdes à des API qui répondent plus moins vite (donc bloquant plus ou moins les threads).

    J'aime le Go et son semblant d'aspect synchone car il me permet de lire le code comme un livre. C'est dire naturellement.

  • [^] # Re: Go Go Go :)

    Posté par  . En réponse au journal recherche-totoz en JavaScript. Évalué à 1.

    Oui sans aucun doute ;)
    Disons que c'est plus un partage d'expérience :p

  • [^] # Re: Go Go Go :)

    Posté par  . En réponse au journal recherche-totoz en JavaScript. Évalué à 0.

    En relisant, je m'aperçois que je n'ai pas fermé le body de la réponse. Donc voici la version corrigée :

    package main
    
    import (
        "encoding/xml"
        "log"
        "net/http"
    )
    
    type totozes struct {
        Name []string `xml:"totoz>name"`
    }
    
    func main() {
        res, err := http.Get("https://totoz.eu/search.xml?terms=plop")
        if err != nil {
            log.Fatal(err)
        }
        defer res.Body.Close()
    
        if expected, actual := http.StatusOK, res.StatusCode; expected != actual {
            log.Fatalf("unexpected status code [actual: %v] [expected: %v]", actual, expected)
        }
    
        var (
            d         = xml.NewDecoder(res.Body)
            totozList totozes
        )
    
        if err := d.Decode(&totozList); err != nil {
            log.Fatal(err)
        }
    
        for _, Name := range totozList.Name {
            log.Println(Name)
        }
    }
  • # Go Go Go :)

    Posté par  . En réponse au journal recherche-totoz en JavaScript. Évalué à 3.

    Hello,
    Pour moi, le Go est dans son élément ici. Les goroutines vous permettent de ne pas vous occuper de l'aspect asynchrone/synchrone.
    Go c'est une application qui tourne avec 10 à 20 Mo d'emprunte mémoire, qui se comporte très bien sur un pod k8s dont les ressources sont inférieures 100 millicore, qui démarre quasi-instantanément, dont le déploiement est simplissime un simple binaire dans un container from scratch, dont la taille sera de quelques mega (ici 6.1Mo pour binaire linux amd64).

    Le tout avec un langage qui reste simple (pour des cas simples), très bien outillé (vet, race …), génial pour la concurrence, la gestion des timeouts/fin de vie (via les context) et qui va utiliser tous les cores disponibles de façon optimale.

    Bref, qu'en pensez vous ?

    https://play.golang.org/p/ElZ99l4WTd-

    package main
    
    import (
        "encoding/xml"
        "log"
        "net/http"
    )
    
    type totozes struct {
        Name []string `xml:"totoz>name"`
    }
    
    func main() {
        res, err := http.Get("https://totoz.eu/search.xml?terms=plop")
        if err != nil {
            log.Fatal(err)
        }
    
        if expected, actual := http.StatusOK, res.StatusCode; expected != actual {
            log.Fatalf("unexpected status code [actual: %v] [expected: %v]", actual, expected)
        }
    
        var (
            d         = xml.NewDecoder(res.Body)
            totozList totozes
        )
    
        if err := d.Decode(&totozList); err != nil {
            log.Fatal(err)
        }
    
        for _, Name := range totozList.Name {
            log.Println(Name)
        }
    }
  • [^] # Re: Microsoft en rêvait

    Posté par  . En réponse au journal IBM achète Red Hat. Évalué à 6.

    Oh mince alors, il nous reste Debian 😁

  • [^] # Re: Go -> Rust

    Posté par  . En réponse au journal Go et Rust, lequel est le remplaçant du C ?. Évalué à 2.

    Pour avoir utiliser les deux (dep et mod). Et bien, je suis contant que Russ ait imposé la vision de la gestion des dépendance qui beaucoup plus simple et suffisamment puissant.

    C'est aussi un outil qui va nettoyer les logiciels qui adoptent des mauvais comportements (je pense à toi k8s qui change son API sur chaque nouvelle version mineure) car ils devront enfin respecter la gestion sémantique

  • [^] # Re: Si tu aimes le risque

    Posté par  . En réponse au journal GNU/Linux Manjaro ! + projet ARM à 300 € !?. Évalué à 1.

    C'est exactement le même ressenti que j'ai. Moi, je n'ai jamais eu de problème avec cette distribution. Elle est très bien fournie grâce Arch tout en limitant les mise à jour, une grosse maj une fois toutes les deux ou trois semaines.

  • [^] # Re: Arch

    Posté par  . En réponse au journal GNU/Linux Manjaro ! + projet ARM à 300 € !?. Évalué à 2.

    Je ne dirai pas ça, j'aime Arch car elle permet de comprendre un peu plus en profondeur Linux. J'aime aussi Arch pour la possibilité de tuning. Elle m'a permis d'installer une Arch Linux sur une clef USB et de tuner le système pour limiter les écriture sur la clef USB en passant tout les écritures en RAM puis lors de l'arrêt du système synchroniser avec rsync. Et surtout j'aime Arch pour la très grande qualité de son wiki.
    Donc, Arch c'est bien, mais Manjaro aussi ;)

  • [^] # Re: Arch

    Posté par  . En réponse au journal GNU/Linux Manjaro ! + projet ARM à 300 € !?. Évalué à 1.

    J'ai suivi leur wiki à la lettre, et je n'ai jamais installé sur mon Arch des paquets provenant de Manjaro.
    Non, les problèmes que j'ai eu ont toujours été des problèmes mineurs mais c'est agaçant. Le dernier en date, si je me souviens bien, a été un problème de certificat lors de la mise à jour. Ce sont des problèmes mineurs mais je n'ai jamais eu ça avec Manjaro.

  • [^] # Re: Arch

    Posté par  . En réponse au journal GNU/Linux Manjaro ! + projet ARM à 300 € !?. Évalué à 1.

    J'utilise les deux et franchement j'ai plus de problèmes avec Archlinux que Manjaro. Mais bon, à mes yeux ce sont de très bonnes distributions. Ce que
    j'aime quand même dans Manjaro, c'est ça simplicité d'installation par rapport à Archlinux (c'est quand même brute de décoffrage ;)) et surtout beaucoup moins de mise à jour. Sur Archlinux, j'en ai plusieurs fois par jour, alors que Manjaro les regroupe en une seule.
    Ça évite les mise à jour du logiciel version x.y.z-1, puis une nouvelle mise à jour du même logiciel en version x.y.z-2.

  • [^] # Re: Si tu aimes le risque

    Posté par  . En réponse au journal GNU/Linux Manjaro ! + projet ARM à 300 € !?. Évalué à 2.

    Personnellement, j'utilise Manjaro comme poste de développement professionnel depuis plusieurs années et c'est stable. J'ai beaucoup moins de problèmes que j'avais avec Fedora lors des montées de version. Bref, je recommande chaudement. C'est une Archlinux (que j'utilise sur ma machine perso) avec beaucoup moins de mise à jour.

  • [^] # Re: Rust et SIMD

    Posté par  . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 2.

    Le vol de travail par exemple est un modèle un peu plus récent
    

    Ce mécanisme est aussi implémenté dans le runtime de Go. En effet, les M goroutines sont réparties sur N threads (un thread par core de la machine) avec un M en général beaucoup plus important N (c'est le principe du scheduler M:N). Le principe du vol de travail (c'est à dire des goroutines en attentes) est mise en œuvre entre les différents threads dans le runtime de Go cf. https://rakyll.org/scheduler/

  • [^] # Re: Rust et SIMD

    Posté par  . En réponse à la dépêche Faut‐il continuer à apprendre le C++ ?. Évalué à 2.

    Il y a un outil pour détecter les race conditions en Go, race detector, mais je ne le trouve pas très efficace.
    

    Juste pour compléter, l'outil race detector est basé sur de la détection des accès concurrents non protégés qui se produisent lors des tests unitaires lancés avec le mode race ou sur une des instances en production qui a été compilée avec le mode race. Les erreurs sont sorties sur l'erreur standard, elles donnent les goroutines incriminées en écriture (voire en lecture) et la zone mémoire (variable, tableau…).
    Il n'analyse pas le code source pour trouver les accès concurrents non protégés (pas d'analyse statistique). Il ne permet pas de garantir que le code est sûr s'il ne détecte rien par contre s'il détecte une erreur c'est vraiment un accès concurrent non protégé qu'il faudra corriger. Il n'est donc pas parfait mais il a le mérite d'exister.
    Pour moi, le couple benchmark ou test unitaire avec plusieurs appels en parallèle (par exemple pour une API WS plusieurs requêtes jouées lors des tests unitaires) et le mode race activé fonctionne très bien. Il me donne une bonne garantie que le code est sûr d'un point de vue des accès concurrences non protégés et il est exécuté dans la CI sur chaque push.

  • [^] # Re: Image from scratch + Go = 🎉

    Posté par  . En réponse au journal Une image de base docker. Évalué à 2. Dernière modification le 08/08/18 à 12:46.

    Et surtout c'est une très bonne couche d'abstraction. Pour le OPS, que tu (en tant que DEV) produises une image légère ou un peu plus grosse (ex: jvm + ton appli) pour l'OPS ç'est un peu près la même chose. Les OPS peuvent in fine facilement l'installé sur un cluster k8s.

  • # Image from scratch + Go = 🎉

    Posté par  . En réponse au journal Une image de base docker. Évalué à 5.

    Pour moi, le couple From scratch + Go est parfait. L'image fait quelques mo, l'empreinte mémoire est d'une vingtaine de mo. Et même si on attribue quelques millicores au pod, le serveur Web de Go se comporte très bien. Bref, je suis satisfait.

  • # awk vs cut

    Posté par  . En réponse au journal taptempo.awk : une approche plus unix ?. Évalué à 0.

    Ok, awk est très puissant.
    Par contre, si je souhaite parser des gros fichiers avec le minimum de ressources ou le plus rapidement possible, alors je préfère utiliser grep+cut pour sa sobriété et rapidité.

  • [^] # Re: Archlinux

    Posté par  . En réponse à la dépêche Sortie d'it-edit version 3.0. Évalué à 2.

    D'où ma question, j'ai cherché aussi et pour fois je n'ai rien trouvé même pas dans AUR. Donc, j'ai (ou on a) sans doute loupé quelque chose.

  • # GOPATH

    Posté par  . En réponse au journal frundis : un langage de balisage sémantique qui mûrit !. Évalué à 2.

    Hello,
    La configuration de la variable d'environnement GOPATH n'est plus nécessaire depuis go 1.8.
    Si elle n'est pas configurée, alors la valeur ${HOME}/go est utilisée.
    https://github.com/golang/go/issues/17262