Glandos a écrit 1215 commentaires

Très bon exemple, en effet. J'ai un ami qui préfère justement largement faire son pain, alors que moi, c'est l'inverse. Je considère justement que c'est plus efficace de confier cette tâche à une seule personne, qui dispose de moyens plus efficaces de faire du pain pour plusieurs. Et c'est meilleur.

Donc oui, l'artisan maçon peut probablement auto-hébergé son site Web, mais c'est long et pas très efficace, donc il achète le service.

Mais là, on parle pas de l'artisan du coin, on parle du premier employeur de France ;)

Je ne comprends toujours pas cette position, qui consiste à acheter un service quand on peut se le fabriquer soi-même.

Et dans l'informatique, c'est pire : on va l'acheter, et personne ne va en profiter, alors qu'avec l'Open Source, c'est possible de capitaliser le travail.

Mais non, l'État pense que c'est pas possible de faire un truc Open Source soi-même, auxquels (soyons fous !) les citoyens pourraient contribuer. C'est fou comme idée.

Je plussoie. Attention, il mettre de l'inox A4 en métallique, parce que le milieu marin, ça fait vraiment rouiller.

Ça dépend de l'architecture… Si c'est de la répartition par DNS avec split horizon régional (parce que bon, l’anycast, c'est quand même pas facile), c'est plus résilient.

Sinon, y a Decentraleyes, mais ça fait pas tout.

Les Européens, je ne sais pas, mais les Canadiens, si.

C'est un format connu, qui possède les mêmes défauts que ceux cités : trop d'informations personnelles sont dedans.

En fait, je dirais que le principal défaut est qu'on dit pas aux gens ce qu'il y a dedans, et qu'ils vont le montrer à tout le monde sans en être conscient.

D'ailleurs… On pourrait bien placer ces 70 ans après la mort de l'auteur dans les discussions…

La plateforme, oui, mais le GPU, y a pas photo. OK, les GPU intégré d'Intel marchent avec des pilotes libres, mais les GPU intégré d'AMD (pour comparer ce qui l'est) sont bien, bien meilleurs.

C'est pas IRCv3 qui est sensé gérer les horloges ?

Bon, OK, pour le déploiement et l'adoption, on repassera…

Est-ce qu'il n'y a pas un biais ici ?

J'ai l'impression qu'il n'y a pas beaucoup plus de gens qui cherchent des failles de sécurité, donc forcément, ils concentrent leurs temps de travail sur un domaine et pas un autre.

Les failles logicielles ne sont pas aussi retentissantes également. Parce qu'elles touchent un seul logiciel en particulier. Et puis, plus personne ne parle des failles immédiatement exploitées (0-day) dans Windows, parce que bon, c'est évident. Des trucs comme Heartbleed ont fait la une parce que quand même, ça touchait tout le monde.

Et puis des failles de sécurité logicielles, il y en a toujours plein, et des marrantes, il suffit de voir tout ce qu'il y a sur les « objets connectés » : caméras, imprimantes, etc.

Mais les failles matérielles sont très singulières (enfin, plus tellement maintenant…) parce qu'elles ne dépendent pas du matériel, et que tous les logiciels qui tournent dessus doivent les prendre en compte. C'est pas facile à corriger :)

Et bien si avec tout ce travail de documentation sur QUIC (la version sur le blog est bien longue et multiple), il y a fort à parier que QUIC est populaire.

Après, va falloir que ça s'installe… Déjà, ce n'est pas facilement disponible en tant que serveur. Heureusement, les clients populaires le supporte.

Et enfin… Faut que le pare-feu de ma boîte accepte de faire passer l'UDP. C'est pas gagné.

Bref, une logique de destruction des ressources primaires.

Voilà. Faut pas être grand clerc pour voir qu'il n'y a pas de respect de la loi : il est où le bouton « Refuser » ?

Mais, mais, c'est censé donné quoi si tu déposes directement des fichiers comme ça dans ton arborescence Git distant ?

Et bien justement, rrsync fait une sorte de chroot. Donc c'est moi qui lui dit où vont se mettre les fichiers. Sur le serveur, il n'y a que des répertoires de git bare finissant en .git. Donc j'ai mis un répertoire à côté (nommé intelligemment rsync_files) dans lequel tout va se mettre, sans se mélanger.

Et sinon, est-ce que Git-FS n'aurait pas été une option ?

J'ai regardé Git-LFS, mais… voilà, j'ai plein de souci. Pas avec Git-LFS, non, mais avec le reste. Ce serveur est en SLES11, avec un openssl trop vieux, et le Git-LFS (du Gitea en conteneur LXC dans un Proxmox) est trop récent, le HTTPS passe pas. Oui, c'est bête. Oui, c'est sur la liste des choses à faire…

Si ce n'est pas dans l'arborescence d'un dépôt et pas de lien avec Git, pourquoi ne pas utiliser un compte idoine.

Si, justement, c'est en rapport. C'est parce que mon projet utilise yarn et sa gestion de paquets hors-ligne (les paquets en .tar.gz sont gardés quelque part pour pouvoir être utilisé par la plateforme de compilation qui n'a pas accès à Internet). Ça s'accumule avec le temps. Au début, je l'avais mis dans le dépôt git directement. Mais voilà, à force de faire les mises à jour, le dépôt git fait 400 Mo, pour 4 Mo de code utile. Donc j'ai cherché une autre solution, sachant que je n'ai pas besoin de l'historique.

Je ne sais pas dans quel genre de boite vous bossez mais dans toutes celles où j'ai mis les pieds à défaut de toujours pouvoir choisir l'OS et le modèle exact de mon éqjipement j'ai toujours pu obtenir des applis et accès me permettant de faire mon travail.

Oui, c'est parfois possible. On peut appeler le support, qui prend la main sur l'ordinateur, et qui installe le logiciel demandé. Pour chaque logiciel, c'est le même protocole.

Par contre en faisant un stage d'une semaine dans un service totalement différent de mon travail, afin de pouvoir avoir une vue de ce que nos utilisateurs vivaient, j'ai réalisé qu'un grand nombre de personnes préfèraient contourner ou vivre avec des problèmes récurents lié à l'informatique plutôt que d'appeler le support ou ouvrir un ticket. Certains se pensent tellement ineptes qu'ils ont peur que le support se moque d'eux. Il y a donc une fracture, pour le moins au niveau de la communication, entre les services IT et leurs utilisateurs.

On a ouvert un ticket parce que notre VPN ne communique pas les bons serveurs DNS lors de la connexion. Ça fait 1 an qu'il est ouvert. Ça fait longtemps qu'on se partage les recettes pour que ça marche « en vrai ».

Et on a le fameux cas du … … … serveur mandataire. Sans blague, il est :
- non transparent : faut que chaque application le gère
- à authentification personnelle : pas d'accès permanent pour les serveurs
- avec des règles strictes : combien de fois je me suis retrouvé bloqué pour lire un blog d'informatique…

Donc oui, ça fait longtemps qu'on a des tunnels SSH pour contourner tout ça.

Mais on s'éloigne du sujet initial, sur le matériel. Dans ma boîte par exemple, il n'y a même pas d'ARPWatch. Et l'instance d'Icinga qui surveille les serveurs n'envoie que des courriels d'alerte, pas d'incident résolus (encore une fois, on a ouvert un ticket, ils ont pas voulu, voilà). Donc autant dire que je ne les regarde pas…

Au final, j'ai parlé avec beaucoup de développeurs, et énormément ont fait la même chose : installer une distribution Linux, soit en dual boot, soit en VM, soit sur une machine séparée. Parce que je constate qu'un Windows de base n'est pas vraiment fait pour le travail d'un développeur, mais plutôt pour celui d'un utilisateur de Microsoft Office.

Y a la version côté employés :

• La politique de sécurité dit : c'est Windows 10 avec Novell ZenWorks (load ×10) et McAfee.
• T'as pas le droit d'enlever la mise en veille automatique au bout de 10 minutes.
• T'as pas le droit d'installer un logiciel non autorisé dans le magasin d'application de la boîte.
• Ton boulot, c'est de paramétrer des variateurs de fréquences par port série avec un logiciel propriétaire.
• …
• T'installes ta distrib' Linux préféré, ça marche.

NOTE: the discoverer states "this vulnerability has no real-world implications."

Comme c'est dit dans le CVE

Comme le dit la présentation, ça marche dans VSCode, mais ça marche plutôt dans un éditeur qui tente d'analyser un dépôt en profondeur.

C'est quand même assez incroyable de pouvoir lire des fichiers en dehors de la racine du projet, et d'ouvrir des connexions TCP dans une macro. Je sais que c'est sûrement « pratique », mais bon, ça ne pouvait que mal se passer.

Non, c'est une blague :

The additional four data center buildings would provide 12 long-term jobs

OK, on a touché le fond. Je précise que j'ai sorti la phrase de son contexte, l'auteur met clairement l'accent sur le fait que ça ne compense pas les inconvénients causés.

Alors, j'ai peut-être mal saisi le cas d'utilisation mais… fish fait ça pas mal.

Par défaut, il affiche la première complétion « qui marche » en gris, et en appuyant sur CTRL+F ça complète l'intégralité de la ligne (ALT+F pour le mot par mot).
« Qui marche » ça veut dire avec des arguments qui, s'ils sont des fichiers, existent encore. Il ne rappelle pas (par défaut) une commande rm dist/ -r si le répertoire n'existe plus.
Et si on en veut une autre, par ordre chronologique, c'est un appui sur la flèche du haut.

C'est moins puissant que fzf, c'est évident.

Quitte à empiler les technos, pourquoi ne pas avoir mis Typescript dans la balance ? (Oui, on fait des blagues de courses)

J'ai dû récemment me mettre à faire un client Web avec tout cet enchevêtrement de bibliothèques et d'outils, et celui que je regrette le moins, c'est bien celui là.

J'avais pas encore vu un demande de modifications autant « moinssée ».

La technologie d'impression est si pointue ?

Oui.

Numériser est devenu un jeu d'enfant. Mais l'inverse est toujours aussi difficile. Par exemple, je viens d'ajouter une imprimante réseau sans pilote. Ça devrait fonctionner. Mais ça m'imprime en 66% dans la page en portrait. Je ne sais pas pourquoi.

Je suis sûr que vous êtes tous presque fiers de voir une page sortir avec les marges de la bonne taille et au bon endroit.

Il doit bien y avoir des cas d'utilisations. Le libriste non intégriste qui veut profiter de son ordinateur comme une station de jeu. Il n'a rien d'autres sous Windows que ça, par exemple.

Je vais sur Wikipédia, et je vois un exemple qui marche avec deno :

// Imports `serve` from the remote Deno standard library, using URL.
import { serve } from "https://deno.land/std@v0.21.0/http/server.ts";

// `serve` function returns an asynchronous iterator, yielding a stream of requests
for await (const req of serve({ port: 8000 })) {
    req.respond({ body: "Hello, World!\n" });
}

Et ça dit :

When running this program, Deno will automatically download and cache the remote standard library files, and compile the code.

OK. Ça choque personne en vrai ? J'imagine que deno vérifie le certificat, mais quand même, c'est extrêmement fragile. Et moi, dans ma boîte, j'ai un environnement CI/CD qui évidemment n'accède pas à Internet. C'est la base de la sécurité de la chaîne d'approvisionnement.

Je sais que Rust et Go font pareil. C'est pas une bonne raison. Je suis d'accord pour dire que c'est moderne, et je pense que c'est une mauvaise idée. J'aurais plutôt vu un truc genre :

• Dans le code import { serve } from 'std@v0.21.0/http/server.ts'
• Dans la conf du projet un truc genre default_repository: https://deno.land/

Et si on veut mettre autre chose, on peut.

Bien sûr, ce cas d'usage ne s'applique qu'à CozyCloud, qui a mis les moyens de faire une belle réplication. Pour l'artisan d'élagage qui a son site à un seul endroit, géré par un webmestre indépendant qui fait ça sur son temps libre, c'est pas pareil…