Bruno Michel a écrit 3285 commentaires

Pendant un paquet d'années, les navigateurs se faisaient concurrence sur les performances et les benchmarks étaient les juges en la matière. Chaque éditeur avait plus ou moins son benchmark où, étonnamment, son navigateur s'en sortait mieux que dans les benchmarks des autres navigateurs. Depuis 2 ou 3 ans, les éditeurs ont changé de bord et abandonnent ces benchmarks. Ils se sont rendus compte qu'ils étaient arrivés à une situation où améliorer le score pour les benchmarks donnait souvent des résultats moins bons dans la vraie vie (un phénomène de sur-optimisation pour des cas spécifiques).

D'autre part, les benchmarks mettent souvent en avant les calculs en JS, ce qui est rarement là que l'impression de vitesse pour les utilisateurs se joue. Les accès au DOM ou savoir charger les bonnes ressources au bon moment sont souvent plus importants.

Bref, aujourd'hui, Firefox est généralement considéré comme le navigateur le plus rapide (suite à pas mal d'optimisations très récentes), suivi de très près par Chrome. Chrome est généralement considéré comme le navigateur le plus avancé en termes de sécurité (séparation en plusieurs processus notamment), suivi de près par Firefox. Derrière, j'entends de temps en temps parler en bien de Falkon, mais les autres navigateurs jouent surtout sur le côté plus léger (moins de fonctionnalités, moins d'extensions, etc.).

A priori, sass-rails va devenir un wrapper autour de sassc-rails : https://github.com/rails/sass-rails/pull/424.

On a maintenant un score de A sur https://tls.imirhil.fr/https/linuxfr.org

C'est effectivement un problème connu depuis un bout de temps. Pour le moment, la communauté Rails n'a pas l'air très décidée sur le chemin à prendre :

• certains proposent effectivement d'utiliser Dart Sass en l'embarquant dans une gem Ruby, mais personne n'a l'air d'avancer dans ce sens (ie écrire du code et être prêt à le maintenir)
• d'autres suggèrent de passer à sassc-rails, mais ce n'est pas très clair si le mainteneur de sassc-rails va encore maintenir cette gem très longtemps, et là encore, il n'y a pas de contributeurs
• enfin, Rails est en train de migrer progressivement de son assets pipeline vers webpack, et possiblement, la manière conseillée d'utiliser sass avec Rails 6.0 sera de passer via webpack.

Bref, pour le moment, le mieux est sûrement de continuer à attendre https://github.com/rails/rails/issues/32896, sachant qu'il n'y a pas d'urgence. Même si la version Ruby de Sass n'est plus prise en charge officiellement, elle ne va pas s'arrêter de marcher du jour au lendemain.

Merci, c'est fusionné et déployé en prod.

Il semblerait qu'une bonne partie de ces critiques de Wayland ne sont plus valides actuellement, voir ont toujours été inexactes/fausses.

Source : https://drewdevault.com/2019/02/10/Wayland-misconceptions-debunked.html

Merci, c'est corrigé.

Je me suis permis d'éditer le commentaire pour corriger le lien vers le Site de dokiel.

J'ai regardé rapidement, ça plante sur un lien avec ce message d'erreur :

URI::InvalidURIError (URI must be ascii only "https://inkscape.org/fr/~wwderw/\u{2605}inkstitch-embroidery-extension")

En lisant rapidement les logs, le problème vient d'un lien avec un titre trop long pour la colonne dans MySQL : 'From the bitstream to the netlist, la démonstration qu'il est possible de faire la rétro-ingéniérie des bitstream'.

Ce qui peut être très pénalisant quand tu dois cloner souvent comme par exemple les serveurs de build.

Pour des serveurs de build, ça se contourne facilement en ne clonant que la branche à builder, voir même que les derniers commits de la branche en question. C'est ce que fait travis par exemple (avec ). On peut même aller plus loin avec les sparse checkout.

le merge request proposant un nouveau nom à eu une réponse via le bug tracker

La réponse vient d'une personne qui n'est pas un des développeurs de weboob et qui regrette l'absence de réponse :

I have no power here and I am a bit sad your ticket has no answer

Bref, on adapte la "règle" pour que ça rentre dans le "acceptable" en faisant de sorte que ça passe pour ce qu'on aime et que ça ne passe pas pour ce qu'on n'aime pas.

Non, je n'adapte pas la règle. Oui, c'est un plus pour un projet que d'être dans les dépôts standard, mais ce n'est pas pour autant que c'est de la censure que d'exclure un projet.

Si je prends un parallèle : sur LinuxFr.org, on refuse les dépêches qui parlent de logiciels propriétaires avec peu de rapport avec Linux. Je ne considère pas ça comme de la censure, vu que ces logiciels peuvent faire trouver d'autres endroits pour parler d'eux. Et pourtant, je suis convaincu que ça serait un plus pour ces projets que d'être cités sur LinuxFr.org (c'est un bon relai pour toucher certains publics).

Je ne considère pas que Debian soit l'autorité compétente sur les publications, émissions et spectacles destinés au public. Debian fournit de base les outils pour utiliser des dépôts tiers et n'a mis en place aucune restriction pour empêcher un dépôt tiers de fournir weboob. Debian ferait de la censure s'ils empêchaient d'avoir weboob sur les ordinateurs qui tournent avec Debian, ce qui n'est pas le cas ici.

Mes affirmations s'appuient sur ce mail de Ian Jackson (ancien Debian Project Leader) : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907199;msg=32. je cite :

Well, others have definitely been trying that. There is an issue in
the upstream tracker (mentioned in the footnote of Niels's message);
https://git.weboob.org/weboob/devel/issues/154

This was reported in early August and has had no responses from the
upstream maintainers, despite several pings from other people. I
think it is clear that upstream are aware of the complaint but are not
dealing with it (perhaps because it's no fun, or perhaps as deliberate
strategy).

[…]

So it's true that we don't know for sure what upstream's current view
is on this situation, but that's not because no-one has tried to talk
to them about it.

[…]

l'équipe Debian a contacté les développeurs de Weboob par d'autres canaux (mails a priori) et n'a vraiment reçu aucune réponse

En fait, il y a aussi cette entrée sur le bugtracker de weboob : https://git.weboob.org/weboob/devel/issues/154

Ils ont accepté les merge request pour virer les insultes; je n'appelle pas ça aucun effort.

Je n'ai pas été très clair :

• l'équipe Debian n'a pas fait cette merge request, j'ai mis la merge request que pour illustrer les commentaires litigieux
• l'équipe Debian a contacté les développeurs de Weboob par d'autres canaux (mails a priori) et n'a vraiment reçu aucune réponse
• par aucun effort, je voulais dire que les développeurs de Weboob n'ont fait aucun effort pour collaborer avec l'équipe Anti harrasement de Debian.

les distros sont de plus en plus lisse, et acceptent de moins en moins l'humour

Dans le cas de weboob, on peut difficilement qualifier ça d'humour. L'article l'explique mal mais la décision de Debian ne s'appuie pas sur le nom weboob et les logos associés. Quand la question avait initialement été levée, Debian avait d'abord choisi de conserver le paquet. En parallèle, l'équipe Anti-Harassment de Debian a essayé de travailler avec les développeurs de weboob pour améliorer les choses. Ils ont suggéré de trouver un autre nom (mais ça restait une simple suggestion, pas une obligation ou une menace) et surtout il y a eu une demande pour retirer des commentaires homophobes du code (cf https://git.weboob.org/weboob/devel/merge_requests/228/diffs). Les développeurs de weboob n'ont fait aucun effort, pas même de répondre à l'équipe Debian pour leur donner leur point de vue. Et c'est tout ce contexte ensemble qui a mené à inverser la décision et à retirer le paquet de Debian.

Je ne sais pas quel a pu être le problème, mais le journal est maintenant en ligne ici : https://linuxfr.org/users/maxima/journaux/ikos-un-analyseur-statique-developpe-a-la-nasa

LinuxFr.org n'utilise plus les gravatars. Pour modifier son avatar, il suffit de le changer dans les préférences.

Redo est une autre alternative à Make. Je serais curieux d'avoir l'avis de l'auteur de smk pour comparer les deux. Par exemple, est-ce que smk s'appuie uniquement sur le mtime pour savoir si un fichier a été modifié depuis la dernière exécution d'une commande ? L'auteur de redo considère cela comme étant fragile : https://apenwarr.ca/log/20181113.

Sinon, j'ai vu passer https://github.com/jacereda/fsatrace qui pourrait aider l'auteur :

This tool injects code into other applications in order to trace file accesses. This can be useful for things like build systems, since it allows to automatically generate dependencies in a toolchain-agnostic way or to ensure declared dependencies match the real ones.

En fait, c'est volontaire, j'avais eu pas mal de retours de personnes qui voulaient plus de densité pour les liens que pour les autres contenus. C'est aussi le cas sur la page d'accueil pour les personnes qui ont activé les liens sur leur page d'accueil via les préférences.

Ça va dépendre des langages, mais certains autorise les types unions. Ici, ça dira que ça retourne soit une chaîne de caractères, soit un entier, soit null. J'imagine que d'autres langages peuvent essayer de trouver un ancêtre commun, genre Object (je n'ai pas d'exemple d'un tel langage en tête). Enfin, certains langages vont juste donner une erreur à la compilation.

Globalement, ça dépend surtout de la manière dont les types sont définis par le langage, pas vraiment de l'inférence de type. Même sur un tel exemple, le type donné par l'inférence de type sera très certainement le même que celui qu'un humain aurait donné.

Essaye de faire un apt install libsodium-dev en root. Je dirais que c'est une bibliothèque en C dont thrussh-libsodium est un wrapper et que cette dépendance de pijul a donc besoin de trouver la bibliothèque en question.

En go, on écrit les types des paramètres et des valeurs retournées des fonctions. Par contre, on a de l'inférence de type dans le corps de la fonction. Exemple :

func computeMeanOfTemperatures(nb int) float64 {
    temperatures := getLastTemperatures(nb)
    sum := 0.0
    for _, t := range temperatures {
        sum += t
    }
    return sum / len(temperatures)
}

Je trouve que c'est un bon équilibre.