Tarnyko a écrit 490 commentaires

En fait, comme le dit @David Demelier ci-dessous (et si j'ai bien interprété sa réponse qui avait l'air en rapport),
appliquer "volatile" à la variable ne va pas forcément empêcher le compilo de la sortir, comme cité ici (même si je reconnais que c'est capillotracté, et perso je n'avais même pas réussi à le reproduire).

C'est pour cette raison que, sur le conseil d'un ami qui se reconnaîtra -cf les logs de commit ;-), j'ai appliqué la même logique que la bibliothèque Botan en le mettant plutôt sur le pointeur de fonction.

Effectivement !
Et en effet si tu regardes, c'est ce qui est fait ici dans le pire des cas :

// ici on gère toutes les architectures connues
#else

static void* (*volatile memset_explicit_unk)(void*, int, size_t) = memset;

#endif

Je dis le "pire", car cela fait une indirection qui tape sur le pointeur de fonction de la lib C.

Très suffisant bien sûr ! Mais juste potentiellement moins efficace que d'avoir soit :
- une implémentation locale qui tirerait un assembleur adapté ;
- son propre assembleur adapté :-)
et le fait que ça verrouille une petite zone mémoire pour le besoin.

(tu le sais bien sûr, mais je précise pour les non-initiés : il ne faut pas appliquer "volatile" sur la variable de la zone à effacer -ici "password"- mais sur l'appel de fonction comme ci-dessus)

Propre (même si je n'utilise pas Clang) !

Pour ceux qui passeraient rapidement et auraient du mal à saisir: memcpy() est une fonction C bas niveau qui permet de copier rapidement une zone mémoire "telle quelle".
Ça ne pose pas de problème en C lui-même ; mais en C++ qui est un langage objet plein de magie (smart pointers, références, constructeurs et destructeurs…), lui passer un objet de ce genre n'est justement 1) en général pas ce qu'on veut vraiment faire 2) un portail potentiel vers le fun !

Ouais il triche.
Limite il fait du poutaclique.
Mais comme c'est mon langage de réf', je râle pas -encore- trop ;)

Par exemple ?

Je me goure ou alors c'est le cas d'usage typique du Flash ;-) ?

Installé… parfait, ça marche, merci !

Maintenant il me reste à trouver 1) un ami 2) un 2ème Android
pour tester toussa 😉.

Wow, merci pour la réponse 😀!

Eh bien du coup, je te le confirme, preuve à l'appui :

09-27 21:12:54.142 31981 31981 E AndroidRuntime: FATAL EXCEPTION: main
09-27 21:12:54.142 31981 31981 E AndroidRuntime: Process: bim.app, PID: 31981
09-27 21:12:54.142 31981 31981 E AndroidRuntime: java.lang.NoSuchMethodError: No static method createPredefined(I)Landroid/os/VibrationEffect; in class Landroid/os/VibrationEffect; or its super classes (declaration of 'android.os.VibrationEffect' appears in /system/framework/framework.jar!classes2.dex)


Hello Julien, ça a l'air cool !

Juste, parmi les infos souvent omises que j'aurais aimées trouver sur la page des releases, il y aurait la version minimale d'Android et les éventuelles dépendances (genre Google Play framework etc).

Ma remarque n'est pas innocente : j'ai installé l'APK et il ne démarre pas sur mon Android 9 habituel (bref écran noir, puis retour au homescreen).
Je n'ai pas le nécessaire ici pour t'en dire plus avec Logcat (ou son équivalent); par contre si tu veux bien me renseigner, je peux regarder -pour lundi au plus tard.

google à décidé d’arrêter google pay sur android 8

Il n'y a jamais vraiment eu de solution à ça ; ni sur Android, ni ailleurs.

Sinon les astuces sont sympa !

En réalité, je viens de regarder, tout dépend du contexte…

NVIDIA fournit-lui même des compositeurs Wayland pour ses distribs embarquées, par exemple DriveOS :

The full source code to the NVIDIA implementation of Weston is in:
drive-linux/samples/wayland/weston

(le code source en question nécessite un compte développeur NVIDIA)

Sur Wayland, je quand même assez d'accord qu'il ne cherche réellement à supporter que les OS qu'il fournit lui-même (Tegra et DriveOS). Dans ce contexte, un Linux non-standard et encore pire *BSD, ué on en est loin.

Merci beaucoup pour le tuto!
Ne prévoyant pas d'utiliser IPv6 dans l'immédiat, c'est surtout la partie UPnP qui m'a interessée : ne la connaissant qu'en utilisateur côté desktop, une install serveur me permettrait de faire des ajustements pour plein de cas.

Ici effectivement le cas est plus complexe: ces interfaces des drivers NVIDIA sont une cible mouvante. On a besoin d'une version récente du système graphique (modules noyau compris) sans sacrifier à la stabilité sur le reste de l'OS…
Les mecs qui bossent dessus ont typiquement une install sur mesure. Là c'est déjà pas mal que ça marchotte.

Ah OK. Dommage… ça a l'air à la fois plus grave et pas lié au GPU; mais tout est possible avec des drivers :).

Après on peut demander à Weston de logger extensivement :

weston --backend=drm --renderer=gl --log=$HOME/weston.log

peut-être y aura-t-il des lignes intéressantes à partir du moment où on perd l'input?

Intéressant.

Et ça, ça ressemble à un problème avec libinput.
Dans le temps Weston utilisait udev comme Xorg; par contre le réactiver c'est pas trivial, c'est un flag à la compil' (si tant est que le code existe encore).

Tu peux encore switcher vers une console fullscreen (avec [Ctrl]-[Alt]-[F4] p.ex.) quand ça se produit ?
Si oui, que se passe-t-il en retournant à Weston (qui lui doit être mappé sur [F1] ou [F7] de mémoire) ?

Aujourd'hui, les 2 drivers ont normalement le nécessaire pour faire tourner Wayland.

Plutôt que Sway (je crois basé sur wlroots), pourrais-tu essayer le compositeur de référence Weston -en général plus à jour sur le support des derniers drivers?

sudo apt install weston
weston --backend=drm --renderer=gl
# en cas d'échec:
# weston --backend=drm --renderer=pixman

Il contient une icône pour lancer un terminal; tu peux ensuite lancer ce que tu veux à partir de là.

Et aussi, je suppose que tu utilises un navigateur… si c'est une base Chrome, il faut savoir qu'il abuse d'extensions Wayland/GL vraiment spécifiques et pas bien gérées partout.
Pourrais-tu voir si ça se produit davantage avec lui; et si oui, éventuellement essayer Firefox par comparaison?

En tant qu'homme engagé..
…je viens d'installer wcurl sur toutes mes distributions.
Un petit coup pour l'homme, un grand coup pour le progrès social !

Ça dépend si c'est un flim de voleur ou d'homme qui a la classe.

Un tel batch est à faire oui !
Perso je ne saurai m'engager sur aucun délai ; sauf que je posterai le résultat ici pour sûr :-).

C'est le taux de compression qui ne va pas. Il ne faut pas mettre le même taux vu que la qualité de compression est supérieure avec jpegli.

Effectivement 😲 !
Je viens de tester en double-aveugle avec Joritro (un camarade de code !) et ces paramètres/ résultats :
- JPEG : 80% (23,5 Ko)
- JPEG-LI : 60% (21,0 Ko)

Et là 2,5 Ko de moins pour la version JPEG-LI -c'était prévisible- mais oui elle est également plus jolie "à l'oeil" avec notamment moins de pâtés irréguliers dans l'espace central.

Je te remercie beaucoup, et vais du coup considérer cette lib pour mes traitements !

More recently, the JPEG-XL team at Google has built yet another JPEG encoder, jpegli, which is both faster and better than even mozjpeg. It is based on lessons learned from guetzli and libjxl, and offers a very attractive trade-off: it is very fast, compresses better than WebP and even high-speed AVIF, while still producing good old JPEG files that are supported everywhere.

Une note là-dessus.

Je viens d'essayer. Plus précisément:
- j'ai pris l'exemple C de JPEG-Turbo;
- j'ai appliqué ce patch (qui rend l'exemple "standard" en retirant le format 12-bits qui n'existe pas partout) et compilé ;
- j'ai executé 2 fois,
1x avec JPEG-Turbo, 1x avec JXL-jpegli:

./example compress -quality 80 test-jpegturbo.jpg

LD_LIBRARY_PATH=$MYPATH/libjpegli  ./example compress -quality 80 test-jpegli.jpg

Il en ressort que la 2ème image produite par jpegli est entre 3-5 Ko plus grosse.
C'est peut-être effectivement plus rapide sur des traitements de grosses images (ou des lots de grosses images) ; mais comme la taille était mon critère, je juge bon de l'indiquer.

Si ça peut aider,

Ce message signifie que la machine n'a pas réussi à se connecter avec son compte d'ordinateur nommé :

NOM_MACHINE$

dans la section "Ordinateurs" d'AD.

Ça se produit en général quand l'ordi esr resté déconnecté trop longtemps et que le contrôleur a changé son mot de passe sans qu'il en soit informé.

Ici le problème serait plutôt sur le protocole d'échange des clés Kerberos ou dudit mot de passe.

Salut,
De mémoire, ce qu'il se passe est qu'Android n'a pas réussi à initialiser son système graphique.

C'est probablement dû au fait que le noyau démarre en mode graphique KMS, bien pour les distros "bureau" mais dont Android, faute de driver dédié, ne sait pas forcément quoi faire.

La solution était de s'inspirer de ce tuto,
çàd interrompre le boot avec la touche Tab, ajouter ce genre de paramètre à la ligne "kernel" :

nomodeset vga=91

et reprendre avec la touche Entrée.

Une fois que ça marche, on peut l'inscrire définitivement en modifiant le fichier Grub ; mais ça je te laisse chercher ;-).

En gros le texte de LWN, c'est un (r)appel à la civilité.

Qui n'aboutira sans doute pas à la fermeture des commentaires, car sans commentaires ni polémiques, qui viendra encore ?
LWN et autres ont beau produire de beaux résumés, sans les réactions parfois très opinionnées de profils impliqués dans l'OSS, ça sonnerait rapidement creux… Imaginez LinuxFR comme ça !

Le "max X commentaire PAR utilisateur PAR jour" par contre, c'est une option intéressante.
Car un gars qui passe sa journée à spammer le site, c'est sûrement pas un profil sérieux…
… et un profil sérieux est de son côté bien trop occupé pour même s'apercevoir de la présence du quota !

A moins d'avoir le compilo rust capable de lire des .h

Je suppose que tu fais référence à ce genre d'usage ?

plus rapide de mettre un peu de Rust dans le C pour améliorer les choses.

Je suis dans l'embarqué aussi, où C++ est quand même assez toléré de mon côté (d'où ma mention) et a l'avantage de l'écosystème installé.
Rust je pousse pour à mort ; c'est quasi le cas d'usage idéal ! Juste pour les projets déjà installés, il est parfois considéré "trop récent" ou trop peu riche en devs par les décideurs…

(après si tu réfères à un mélange que je ne connais pas, je suis intéressé !)