Pinaraf a écrit 3419 commentaires

  • [^] # Re: Merci !

    Posté par  . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 5.

    Ben justement, ce n'est pas ce que fait sslh, merci bien. J'ai déjà fait ce genre de chose avec de l'openvpn et du https, ça se distingue très bien sans regarder le contenu des paquets. Mais distinguer ssh toto@tutu1 et ssh toto@tutu2 quand tutu1 et tutu2 pointent sur la même IP, c'est pas la même histoire. Ou alors on a trouvé une énorme faille de sécurité dans SSH et personne ne m'a rien dit ?

  • [^] # Re: My 2 cents

    Posté par  . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 7.

    Combien, 30 ans d'éducation réseau à casser ? Ça va être dur… :)

    Prenons Marcel Toto, fier propriétaire du bloc 2000:2001:2002:2000::/56 attribué par son fournisseur d'accès internet RFC.com.
    Marcel décide de répartir son réseau en 3 sous-réseaux:
    - 2000:2001:2002:2001::/64 pour ses serveurs et services réseau principaux…
    - 2000:2001:2002:2002::/64 pour ses ordinateurs de bureau, portables…
    - 2000:2001:2002:2066::/64 pour le wifi invité.

    Quand son serveur, 2000:2001:2002:2001::73, échange avec son ordinateur de bureau, 2000:2001:2002:2002::42, la communication va se faire sans traduction d'adresse, vu que les adresses sont uniques. L'équipement qui passera les paquets pourrait avoir, mettons, 2000:2001:2002:2001::1 et 2000:2001:2002:2002::1, il n'aura pas à traduire d'adresses pour autant. Il fera un travail de passe-plat, comme n'importe quel switch réseau sait le faire.

    C'est justement là la différence avec le NAT.
    En IPv4, on a le serveur de linuxfr.org qui parle à mon switch port TCP 12345, et le switch pour chaque paquet doit dire «ho, c'est pour moi, merc… et merde, non, c'est encore le gros lourd qui veut passer un message à l'autre con… bon, je colle une nouvelle étiquette, et c'est parti».
    Bien sûr, juste sur mon réseau local, serveurs et clients peuvent se parler sans NAT, sans trop se prendre la tête… par contre quand tu commences à avoir des serveurs exposés sur l'extérieur, ça devient plus rigolo à router justement à cause du NAT. Alors qu'en IPv6, tu n'as pas à faire tout ça.

    Tu noteras par contre que je n'ai pas parler du firewall pour ce qui vient de l'extérieur ou ce qui va entre chaque zones, ni de l'allocation des IPs, ce sont d'autres sujets (on répète tous ensemble : «le NAT n'est pas une sécurité» − https://blog.webernetz.net/why-nat-has-nothing-to-do-with-security/)

  • [^] # Re: Merci !

    Posté par  . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 6.

    Hum, je ne vois pas comment tu fais.
    Prenons un cas simple : SSH.
    Imaginons que tu doives avoir obligatoirement du SFTP sur le port 22 pour un logiciel ne supportant pas autre chose (j'ai déjà vu ça avec des banques), mais que le port 22 est déjà utilisé pour ton SSH normal et que tu ne peux pas le bouger. Comment tu veux faire la distinction sans avoir deux adresses IP ? Au niveau réseau, le nom d'hôte disparait, tu reçois des paquets TCP à destination de 1.2.3.4:22. Éventuellement, ils peuvent contenir une info sur la cible, comme le SNI de HTTPS… Mais donc il faut que ton reverse proxy gère spécifiquement chaque protocole ?
    Ça me parait juste infaisable sans avoir des adresses IP en stock… et donc sans IPv6 pour la plupart des gens qui veulent faire de l'auto-hébergement, ou sur le long-terme.

  • [^] # Re: Merci !

    Posté par  . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 5.

    Et tu fais quoi pour un service qui ne soit pas en HTTP/HTTPS ? Je sais que c'est plus à la mode, mais y'a quand même des protocoles plus adaptés pour certaines taches que HTTP :)

  • [^] # Re: L’avenir et le passé

    Posté par  . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 5.

    Malheureusement, ce que fait systemd est nécessairement invasif. À partir du moment où tu veux gérer les services comme ça, tu te retrouves à intégrer beaucoup de choses… Bon, réimplémenter un client SNTP ou DHCP, faut pas déconner, c'est pas nécessaire.

    Une excellente présentation sur ce sujet, sans à mes yeux de fanatisme pro-systemd:
    https://www.youtube.com/watch?v=o_AIw9bGogo

  • # Tant que le fonds fond pas…

    Posté par  . En réponse au lien Le fonds de développement de Blender a atteint son premier but : 25k€/mois (= 5 devs) . Évalué à 3.

    Petite typo, on ne dit pas le fond mais le fonds…
    Et super pour blender, en espérant que le fonds ne touche pas le fond :)

  • # Nul…

    Posté par  . En réponse au lien Liste à puce des raisons pour lesquelles vous devez arrêter de dire « tiret du 6 » ou « tiret du 8 ». Évalué à 10.

    C'est parce que numerama a maintenant ce type de «contenu» que je ne mets plus dans mes catégories importantes de flux RSS…
    Donc désormais l'azerty issu de l'IBM PC est l'azerty de Windows, il n'existe plus d'ordinateurs non Apple visibles par les plus jeunes, à part «les vieux Compaq de la salle de technologies du collège» (Compaq, disparu en 2002)…
    Leur but semble d'être juste de faire à peu de frais du contenu qui apportera assez de clics pour la pub.

  • [^] # Re: Pourquoi en basic?

    Posté par  . En réponse à la dépêche Sortie de Gambas 3.12. Évalué à 3.

    Je n'ai pas encore vu un environnement de dév de la sorte sous Linux (environnement tout intégré, avec GUI, etc.), c'est chose faite, bravo. :)

    Il y a également Lazarus (Freepascal) qui est pas mal du tout en tout intégré. J'attends que Gambas 3.12 soit dans ma debian pour jouer un peu avec, par contre l'absence de support de windows va m'empêcher de le mettre en avant auprès de connaissances qui n'ont pas accès à mieux aujourd'hui que Excel/Access et les macros :/

  • [^] # Re: telle est la question

    Posté par  . En réponse au lien Talos 2 - POWER9 : du vrai-vrai open hardware cette fois? . Évalué à 3.

    Raptor CS affirme que le microcode est ouvert. Et le POWER est développé par la fondation OpenPOWER, où tout le monde peut devenir membre. Donc ça semble plus ouvert que fermé…

  • [^] # Re: Octave ?

    Posté par  . En réponse à la dépêche Un peu d’Open Hardware pour la rentrée (et beaucoup de LinuxBoot). Évalué à 10. Dernière modification le 01/09/18 à 19:31.

    Alors je ne connais pas la relation entre vejmarie et OVH/Octave, mais ayant travaillé un certain temps à OVH je peux donner des pistes d'interprétation.

    OVH se vante d'innover notamment sur le matériel, d'embrasser l'open source, de contribuer… Du coup des projet comme coreboot ou linuxboot, qui peuvent apporter moultes avantages pour des grands opérateurs de réseau, devraient intéresser et pousser à contribuer le «n°1 européen du cloud».
    Mais à moins d'un changement radical depuis mon départ il y a 3 ans, OVH n'est qu'un intégrateur, gros certes, mais un intégrateur, donc je les vois vraiment mal contribuer à linuxboot. D'autant plus que pour ce qui est du cloud, ils sont maqués depuis longtemps avec VMWare, et le private cloud à base de VMWare étant devenu une belle vache à lait (au sens économique), à moins que VMWare se mette à certifier des machines sous linuxboot pour ESXI… c'est vraiment pas près d'arriver.

  • [^] # Re: Argument fallacieux

    Posté par  . En réponse au journal quand Oracle fait les affaires de Azul.. Évalué à 10. Dernière modification le 22/08/18 à 17:31.

    Je suis très preneur d'un journal sur LLVM orienté JIT !

    J'aurais mieux fait de fermer ma gueule :)

    Ça viendra, mais faut d'abord que je fasse tout un gros dev avec une vraie bibliothèque de JIT pour comparer proprement. Du coup ça va être long. Le cœur du problème pour les cas que j'ai vu : le code est émis en une seule fois (lourdement), et jamais revu après. Et je suis tombé sur au moins un cas où une phase d'optimisation indispensable pour de bonnes perfs est dans l'étape de codegen, qui n'est pas configurable.
    Dans le cas qui m'intéresse, PostgreSQL 11, je suis convaincu de l'utilité du JIT par LLVM pour les grosses requêtes où le gain CPU va exploser le temps de compilation requis, mais je suis certain que ça sera en dessous des performances d'un vrai compilateur à la volée, et même dans certains cas en dessous des performances de PG sans compilation (cf. http://www.postgresql-archive.org/PATCH-LLVM-tuple-deforming-improvements-td6029385.html par exemple). Par contre, une solution bien plus légère de compilation/optimisation progressive du bytecode… ça devrait couvrir cette deuxième partie du spectre.

    Je pense que les cas de unladden swallow (interpréteur python utilisant LLVM - http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html) ou encore de webkit (abandon de LLVM pour le JIT - https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/) sont assez clairs. Il est des cas que LLVM couvre excellemment, mais il ne faut absolument pas croire qu'il s'agit là du marteau universel. Ce marteau n'existe pas :)
    Les langages dynamiques, l'absence d'optimisation progressive avec retour arrière… ce sont des défis que LLVM ne peut pas relever aujourd'hui. LLVM est conçu avec un modèle complètement statique, parfait pour de nombreux langages. Pour Java, à voir, mais je pense que des choses comme invokeddynamic risquent d'y perdre des plumes.

  • # Argument fallacieux

    Posté par  . En réponse au journal quand Oracle fait les affaires de Azul.. Évalué à 10.

    Et si cette JVM de course augmentait tellement les performances des applications que son coût serait inférieure au temps nécessaire à optimiser le code ?

    Marmotte + chocolat + aluminium…

    Aucune JVM, aucun compilateur au monde ne saura lutter contre le bâclage du développement.

    Je vais prendre un exemple tout simple où je ne vois pas comment un outil aurait pu corriger le soucis. C'était il y a quelques années, je travaillais sur un interpréteur (très) mal codé pour un langage basic-esque quelconque (j'insiste sur la deuxième syllabe). Un bytecode était généré en mémoire, puis exécuté dans plusieurs threads en même temps (avec des données différentes). Et le temps d'exécution était linéaire avec le nombre de threads. 1 thread − 10 secondes, 2 threads − 20 secondes, 3 threads − 30 secondes (véridique).
    Après quelques heures d'analyse, j'ai trouvé qu'à chaque exécution d'une instruction du bytecode, un lock était pris sur un tableau partagé entre tous les threads. Il a suffit de s'assurer que le tableau soit en lecture seule pour tout le monde pour supprimer le lock et avoir un temps linéaire, mais dans le bon sens.

    Je n'ai pas fait de Java depuis trop longtemps pour donner des exemples concrets de synchronized et cie, mais ce genre de situation est bien trop courante et surtout hors d'atteinte des VMs ou des compilateurs. Quand bien même tu prouvais que la variable est effectivement bien en lecture seule passé un certain point, c'est un prédicat trop fragile s'il n'est pas garanti par le code, sinon les performances seront aléatoires : un petit changement casse cette optimisation et c'en est fini.

    Et quand bien même cette VM était magiquement rapide… la JVM de base est déjà hyper optimisée mine de rien, je serais vraiment surpris de voir une différence de perfs qui soit significative. Certes c'est beau de dire «on utilise LLVM ça poutre sa race», mais la JVM a eu des années d'optimisation que le mode JIT de LLVM n'a pas eu (et pour l'avoir utilisé, c'est vraiment pas dans l'esprit de LLVM le JIT, j'en ferai un journal à l'occasion). Donc où sont les chiffres ?

  • [^] # Re: Projet intéressant académiquement

    Posté par  . En réponse à la dépêche Haiku a 17 ans. Évalué à 7.

    Et essayer de prendre la place de Windows, iOS c'est mort aussi. Remplacer les linux, FreeBSD…ce sera difficile aussi.

    Mon but dans la vie ? conquérir le monde !

    La mode du cloud et du tout dans le navigateur web a cet avantage qu'il est désormais moins pénalisant d'être sur une plateforme exotique : de plus en plus de choses passent, lourdement, mais passent avec un navigateur web.
    Du coup, pourquoi faudrait-il avoir pour seul but d'être premier sur un marché ? Nous ne sommes pas sur un projet d'entreprise mais un projet d'individus qui s'amusent. Et ça fait un bien fou…

  • # Lecteur de flux RSS…

    Posté par  . En réponse au journal Recherche sur DLFP. Évalué à 7.

    J'utilise mon lecteur de flux RSS pour chercher toutes les publications depuis 2008. C'est en général suffisant. :)

  • [^] # Re: Apprendre le codage, développeur web, etc ?

    Posté par  . En réponse à la dépêche 20 ans de LinuxFr.org : entretiens avec les visiteurs (1). Évalué à 4.

    Le soucis du web c'est que ça t'ajoute des tas de concepts à apprendre en plus de l'apprentissage de la programmation en elle-même.
    Alors sur un hello nom, tu as du HTML et du JavaScript, ça peut passer.
    Mais prenons un exemple tout simple : je veux afficher à l'écran le contenu d'un fichier (c'est avec ce genre d'exemple que j'apprenais quand j'étais petit). Pour faire ça en web, soit tu passes en 100% client avec des APIs de manipulation de fichier en JS (et je suis pas sûr qu'elles soient simples à manipuler), soit tu passes en client/serveur avec un upload de fichier à gérer. T'as à prendre en compte plein de concepts rigolos pour faire ça proprement. En desktop, avec Lazarus, tu as besoin de glisser sur ta fenêtre 1 bouton, un champ texte, un dialogue d'ouverture de fichiers, et écrire, grosso merdo…

      if OpenDialog1.Execute then
      begin
        Memo1.Lines.Clear;
        Memo1.Lines.LoadFromFile(OpenDialog1.FileName);
      end;

    Je ne dis pas que c'est la panacée. Mais ça permet d'apprendre un seul ensemble langage/bibliothèque, sans avoir en plus à y ajouter des notions de client/serveur.

    Après quand j'étais vraiment petit, c'était le BASIC Thomson. Là c'était simple, et un casse briques tenait sur une page de code, donc pour apprendre c'était vraiment fun (enfin, je trouvais…)

  • [^] # Re: Apprendre le codage, développeur web, etc ?

    Posté par  . En réponse à la dépêche 20 ans de LinuxFr.org : entretiens avec les visiteurs (1). Évalué à 3.

    D’une manière générale, le Web est probablement ce qui est le plus abordable en informatique.

    Kof !

    Après avoir dit qu'il faut connaître HTML, CSS, JavaScript côté client, plus un autre langage côté serveur… On partage pas le même principe pour «abordable». :)

    J'aurais dit la programmation côté bureau avec un environnement comme Lazarus pour un truc abordable (mais la doc pêche, surtout en français). Tu apprends un langage, le Pascal, et tu ne fais du code que pour la logique de l'application. Rien à écrire pour la partie hyper pénible du dessin des interfaces graphiques. Le défaut par contre, c'est où on va après ça. Il me semble qu'on peut faire de l'Android et de l'iOS avec, mais n'ayant ni l'un ni l'autre je n'ai jamais tenté…

  • # Joyeux nanniversaire DLFP

    Posté par  . En réponse à la dépêche 20 ans de LinuxFr.org : entretiens avec les visiteurs (1). Évalué à 10. Dernière modification le 09/07/18 à 15:57.

    Odoo ; le code est toujours d'excellente facture et la maintenance est assurée

    Encore heureux que le code d'un ERP soit d'excellente facture… :)

  • [^] # Re: HT et performances...

    Posté par  . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed . Évalué à 5.

    Chanceux, des itanium…

    Plus sérieusement, étant donné l'architecture complètement différente des itanium par rapport aux x86, je ne suis pas certain que l'on puisse transposer le gain en performances entre les architectures… De plus, selon les logiciels utilisés et le niveau d'optimisation atteint (utiliser complètement le CPU d'un itanium semble être un art obscur) tu pourrais avoir un terrain bien plus favorable à l'HT.

  • [^] # Re: HT et performances...

    Posté par  . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed . Évalué à 7.

    Dans son autre usage, compilation et construction de paquets et de systèmes, j'ai pu mesurer les écarts sur un build complet:

    Avec: 1h20
    Sans: 1h30

    Rien de spectaculaire.

    Heu… 12,5% de pertes quand on désactive HT ça te suffit pas (Ou 11,11% de gain, on va pas chipoter) ? L'HT va pas faire un x2 en perfs, mais si l'HT était bien implémenté il serait idiot de ne pas l'activer.

  • # HT et performances...

    Posté par  . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed . Évalué à 10.

    Si encore une fois, la désactivation de l'Hyper-threading pourrait même avoir des effets positifs sur les performances, autant en finir une fois pour toute.

    Comme souvent, les performances dépendent du cas envisagé pour la comparaison. L'hyper threading est positif pour les performances sur de nombreux cas, c'est pour cela qu'il est activé par défaut, ils sont pas idiots à ce point.

    Vivement les détails sur cette faille en tout cas. Impacte-t-elle uniquement Intel ? Est-ce corrigeable par le microcode ? Le même principe serait-il exploitable contre du SPARC ou du POWER ?

  • [^] # Re: Retour d'expérience

    Posté par  . En réponse au journal Sortie de Sailfish OS 2.2.0. Évalué à 3.

    J'ai eu un hardreset sur mon Jolla 1 également, mais depuis toutes les mises à jour sont passées sans soucis et je suis actuellement en 2.2.0…

  • # JIT

    Posté par  . En réponse au lien Un grand tour des nouveautés de PostgreSQL 11 qui arrive bientôt. Évalué à 5.

    L'intégration de la compilation à la volée avec LLVM des requêtes n'est pas assez mise en avant de manière générale.
    Même sur des requêtes en dessous de la seconde, malgré les ~20 ms de compilation, on peut avoir une division par deux du temps d'exécution… C'est bluffant et «magique»…

  • [^] # Re: Et avec Github...

    Posté par  . En réponse au journal Microsoft rachète Github. Évalué à 7.

    Il s'appelle NotReleasedYet :)
    J'ai prévu de faire un journal sur ça d'ici quelques semaines, le temps de stabiliser et d'implémenter assez de fonctionnalités pour que ça soit «montrable» sans honte…

  • [^] # Re: Et avec Github...

    Posté par  . En réponse au journal Microsoft rachète Github. Évalué à 9.

    Je pense que j'étais assez explicite précédemment : je bannis les applications web de ma machine, effectivement. Je préfère Marble à * Maps, mon client Slack en Qt au client Slack web, KMail à GMail, LibreOffice à Google Doc…

  • [^] # Re: Et avec Github...

    Posté par  . En réponse au journal Microsoft rachète Github. Évalué à 10.

    On se retrouve avec des "applications" terriblement lentes par rapport aux applications natives. Sur slack par exemple, il m'est arrivé d'attendre une seconde entre ma frappe au clavier et l'affichage dans le champ d'écriture de message. Je ne parle pas de l'envoi hein, juste l'affichage du message en cours de rédaction.
    Et je ne vais pas parler de la consommation de RAM. Mon PC a 8GB de RAM, ce n'est pas pour la gâcher avec chaque application qui bouffe la RAM d'une instance de navigateur web.

    On prend un afficheur de documents et on le transforme en plateforme d'exécution d'applications… Tout va bien ?