Pinaraf a écrit 3682 commentaires

Je sais c'est has-been, c'est pas web devops tout ça machin… mais vous avez quelque chose contre LDAP ?
On stocke dans l'annuaire les utilisateurs, les clés publiques dans un attribut… et ça roule, avec la possibilité de gérer dans l'annuaire des restrictions d'accès par groupe de machine…

Et sinon ne pas remplir des authorized_keys locaux mais les récupérer dynamiquement depuis le serveur, comme ça y'a plus besoin de client qui maintienne les fichiers locaux ? (À la rigueur avec un cache local si le serveur devient injoignable, mais ça reste sujet à débat)

Du tout, juste pratique. Imposer la même heure à tout le monde, de préférence UTC, et on s'emmerde plus avec les fuseaux horaires et les histoires d'hiver/été. On mange à l'heure adaptée localement, on se couche et se lève selon l'heure du soleil… et c'est bien plus simple. Cf https://linuxfr.org/users/zoot/journaux/hs-etes-vous-pour-rester-a-l-heure-d-ete-ou-a-l-heure-d-hiver#comment-1763004

On est d'accord pour dire que 19H, 7H ou 12H12, c'est une simple convention de communication ?
L'heure est un outil de communication, en aucun cas un diktat à suivre pour le rythme biologique. Si demain je pouvais dire à un Portugais et à un Grec de faire une réunion ensemble à 13H, sans devoir m'inquiéter des conversions, ça serait largement mieux.
Le plus naturel serait de ne parler qu'en heure UTC, et on ne se soucie plus des fuseaux.
Vous direz que ça signifie qu'on ne peut plus se douter qu'un rendez-vous à 12H heure locale du correspondant va perturber son repas du midi… mais c'est négliger l'importance des habitudes locales (on mange très tôt le soir en Allemagne par exemple) qui fait que la convention actuelle ne règle guère de problèmes…

=> Le choix de la France ne doit pas dépendre des autres pays (à noter: la Belgique préfère aussi l'heure d'été permanente)

Ça doit carrément. C'est à ça que sert l'Union Européenne, avoir un truc uni (merde, comme dans «union» ? révélation !).

Hier soir je suis allé dans un restaurant à côté de chez moi. Comme souvent. Et donc, comme souvent, j'ai franchi une «frontière» pour ce faire (c'est-à-dire que je suis passé au dessus d'un pont au milieu d'une ville). Si demain les heures devenaient différentes entre la Belgique et la France, le merdier que ce serait pour tous les commerces frontaliers (qu'ils soient français ou belges), pour les habitants… «Bonjour, je voudrais réserver une table pour 20H», et le client arrive à 21H ? Ou à 19H…

Tu peux avoir une vision centriste (du Centre hein, pas du mouvement politique), voire nationaliste… Mais pour les nordistes, les alsaciens, les alpins, les pacaïstes, les pyrénéens… cette décision dépend bien plus de nos voisins. Je me préoccuperais beaucoup moins que Paris soit à une heure de décalage de Lille que si Comines était à une heure de décalage de Comines (l'une des villes séparées en deux par la frontière de 1713 du traité d'Utrecht qui a établi la Lys comme étant la frontière entre les pays)

2 : je sous-entend quand tu n'ajoutes pas un réseau « parallèle » en ULA

Tiens, je croyais que le minitel n'existait plus :)

Nope, je dirais a peu près 17 seulement, ça pourrait être 2 fois plus simple que prévu, si l'administration était mon métier, mais ce n'est pas le cas (ce qui ne m'empêche pas de vouloir savoir comment ça marche).

Je parlais du cas général, je n'ai pas prétendu que tu avais 30 ans d'éducation en réseau (sinon je crois que tu m'écraserais allègrement) :)

Du fait de l'abondance des IPs, donc, il suffit d'affecter les IPs que l'on souhaite utiliser à une machine spécifique et le tour est joué? Du coup, la différence contrairement à IPv4, c'est qu'il n'a pas besoin d'aller ouvrir le protocole suivant (TCP/UDP/ICMP/Que-sais-je/…) d'où un gain de simplicité dans la pile logicielle?

Voilà. La quantité d'adresses IPs et de réseaux disponibles fait qu'il n'est plus nécessaire de jongler avec des adresses publiques/privées, et donc les routeurs ne font que router les IPs, sans regarder plus loin. Cela simplifie considérablement le travail. Sur un gros réseau, avec un fort trafic, la charge CPU pour le NAT n'est pas négligeable, et cela commence à consommer de la RAM. Et je ne dis pas ça comme un troll : dans des clouds professionnels à beaucoup de brouzouf$ par mois, j'ai déjà eu des connexions réseau qui se coupent entre deux systèmes parce qu'ils n'ont pas envoyé de paquet pendant X minutes et que le routeur a une règle pour supprimer périodiquement de la table de NAT les connexions «inactives» (et quand ça coupe, ça te prévient pas, du coup ton prochain paquet part dans un trou noir et ton appli peut faire la gueule)

De toute façon, je suppose qu'il doit y avoir un équivalent au DHCP qui fonctionne plus ou moins comme ceux que l'on utilise pour IPv4, à l'exception du fait de la quantité d'adresses dispo que l'on ne se prive pas pour assigner plusieurs IPs à une même interface, par exemple une IP publique et une IP locale, qui permette éventuellement de ne lancer les services sensibles que sur l'IP locale?

Tu m'auras pas, je le ferai pas ! :)

Allez, on va faire ça en très court : il y a deux protocoles, SLAAC (StateLess Auto Adress Configuration) et DHCPv6. DHCPv6 a des fonctionnalités en plus par rapport à SLAAC (la RFC 6106 est rarement implémentée pour passer les serveurs DNS en SLAAC hélas, et elle est très peu connue), mais normalement tu peux n'utiliser que SLAAC sur la plupart des réseaux.

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 ?

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/)

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.

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 :)

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

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 :)

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.

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 :/

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é…

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.

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.

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 ?

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…

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

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…)

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é…

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… :)

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.

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.