Benoît Sibaud a écrit 9304 commentaires

Encore ces nantis d'OpenBSD !

 __________________________________
/ Do you really want to clone this \
\ project?                         /
 ----------------------------------
 \
  \
     __
    /  \
    |  |
    @  @
    |  |
    || |/
    || ||
    |\_/|
    \___/

(ou Clone Wars « je suis ton père » ?)

Corrigé, merci.

Corrigé, merci.

Corrigé, merci.

Pour Debian Stretch actuellement, les architectures prises en charge :

• 52.8.0esr-1~deb9u1 : amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x

Pour Debian Sid actuellement :

• 60.0.1-5: amd64 arm64 armel armhf i386 ppc64el
• 52.0.2-1: hppa mips mips64el mipsel powerpc ppc64 s390x // donc au moins 5 archi non encore dispo en 60.0 pour Stretch
• 50.1.0-1 [debports]: m68k sparc64
• 48.0-1: kfreebsd-i386
• 47.0.1-1: kfreebsd-amd64

Pour Debian experimental :

• 61.0~b8-1: amd64 arm64 armel armhf i386 ppc64el

Bref il manque encore quelques paquets pour cela (cf source).

Corrigé, merci. (même si la version de la demande est malvenue)

Ça mériterait un tooltip ou une info plus visible sur la barre d'outils (ou ailleurs je ne sais pas trop).

On parle bien des raccourcis clavier ?

Corrigé, merci.

Précision ajoutée dans la dépêche.

Corrigé, merci.

Corrigé, merci.

Du coup, tu as déduit une formule du type consommation structurelle = taille fixe + pourcentage du volume * taille du volume ? (le tout en fonction de la taille des blocs ?).

Ouais ben de mon temps on faisait du pixel art sur Amstrad CPC en redéfinissant les fontes 8x8 en binaire dans du Basic après avoir dessiné sur du papier millimétré… Espèce de jeunes assistés ! (enfin assisté·e·s)

(tiré de man mke2efs)

       -m pourcentage_blocs_réservés
              Indiquer le pourcentage de blocs du système de fichiers réservés pour le superutilisateur. Cela permet d'éviter la fragmentation et permet aux démons lancés  par le  superutilisateur,  comme syslogd(8), de continuer à fonctionner correctement après que les processus non privilégiés ne soient plus autorisés à écrire sur le système de fichiers. La valeur par défaut est de 5 %.

Étrangement ma question en lisant l'article était de trouver des applications au fait de réserver 100% à root…

Cette conclusion est des plus classiques/banales. La plupart des gens s'exprime sur des sujets sans en maîtriser les tenants et les aboutissants (forcément on n'est pas experts spécialisés en tout) : la plupart des personnes qui s'exprime sur le karma, la modération ou les fonctionnalités de LinuxFr.org (pour prendre un exemple que je connais bien) ne connaisse pas les détails techniques, l'historique ou les raisons des choix, mais ont des avis tranchés en général. On ne doit pas leur dire de ne pas s'exprimer, c'est même souhaitable qu'elles s'expriment pour dire ce qui leur plaît, ne leur plaît pas, leurs suggestions, etc. Tout au plus peut-on espérer un peu de pondération/modération dans les propos pour convertir un « Votre xxxx c'est de la merde » ou « Bordel pourquoi vous n'avez pas encore fait ça ? » en « Votre xxx est améliorable pour telle ou telle raison et par tel ou tel moyen » ou « Pourquoi votre xxx fait-il cela ? ». C'est moins présomptueux, plus empathique, moins inflammatoire, plus respectueux, plus intéressant pour les deux parties (le demandeur réfléchit un peu plus aux raisons, et de fait le répondant aussi, tâchant de se rappeler pourquoi c'est comme ça et si ça ne devrait pas être documenté quelque part), et ça rend le poil soyeux et guérit la faim de la guerre des cancers du monde.

C'est dommage de réduire ces sujets à un simple lien je trouve. Il y aurait plus à dire sur RGPD et infrastructures informatiques (ICANN & DNS, GPG, blockchain, etc.).

Tentative de résumé des échanges sur la liste gnupg-devel :

• les serveurs de clé peuvent partager des noms/prénoms/courriels (voire des photos) associés aux clés
• cela se fait sans permettre la suppression et rentrerait en conflit avec le droit à l'oubli
• cela fait partie du fonctionnement (la collecte n'est pas abusive)
• demander des confirmations/informer l'utilisateur à chaque envoi serait contre-productif en termes d'interface utilisateur et de diffusion de la crypto
• un tiers peut collecter les données partagées de toute façon, sans accord utilisateur ou sans respect de la loi (spammeur par exemple)
• techniquement, il n'est pas actuellement possible de marquer « privée »/non diffusable une clé publique (ou de la supprimer). Il faudrait au moins permettre la suppression de la clé (ou au moins de la partie UID nom/prénom/courriel/photo) par le propriétaire de la clé.
• les serveurs SKS ne seraient pas compatibles RGPD, mais d'autres serveurs de clé (celui de Mailvelope est cité) le seraient.
• plusieurs positions plus rassurantes sur l'objectif du RGPD et la position des autorités nationales, comme le fait que ce n'est pas leur but ou le fait qu'elles utilisent aussi GPG
• il est de toute façon utile d'ajouter une politique sur les données sur son serveur de clé (il existe des générateurs)

Précisé, merci.

Une solution est d'utiliser %S, qui marche sur mobile et desktop dans ce cas.

Corrigé, merci.

Corrigé, merci.

(repompe éhontée de https://linuxfr.org/users/antistress/journaux/optimiser-la-recherche-web-dans-firefox#comment-1738469 avec mise à jour de version)

J'utilise aussi les mots-clés et le %s pour compléter l'URL avec Firefox, mais j'ai un petit souci sur mobile (Android Firefox 60.0.1). Si j'associe 'w' à wikipedia par exemple, et que je fais 'w foo bar' dans la barre d'URL, ça donne …/foo%20bar sur desktop (espace OK) et …/foo%2Bbar sur mobile (plus KO). J'ai raté un truc ou je dois ouvrir un bug ?

Alkarex, un des développeurs de FreshRSS a identifié l'origine du souci et poussé une correction sur la branche de développement. Rapide et efficace.

https://github.com/FreshRSS/FreshRSS/pull/1891 (commit)

Corrigé, merci.